synpress

More specific detail: is there any option to change the collation output from the plugin?

Thanks. Has anyone tried using this with Okta that you know of? I gave it a try, and ran into a number of issues, but I suspect they are environment-related. Appreciate any pointers/resources.

Before I added these defines, I noticed that when navigating in/out of the admin settings, sometimes one or more setting would not be there. I also noticed the login action URL had an empty client id. That made me suspicious, so I added my OKTA application credentials in my wp-config.

define(‘OKTA_CLIENT_ID’,'<your_client_id_from_okta>’);
define(‘OKTA_CLIENT_SECRET’,'<your_okta_client_secret>’);
define(‘OKTA_ORG_URL’,'<your_okta_org_url>’);

Once I did that, I began seeing the right information populated. I still need to sort out some other issues with the redirection.

With a minor update to config, now see:

Notice Undefined index: user_pass in /wp-includes/user.php on line 1459
Catchable fatal error: Object of class stdClass could not be converted to string in /wp-includes/formatting.php on line 4669

The plugin seemed to be losing settings – once I added them via DEFINE, I began seeing more consistent results.

Hi John. I tried it out on our QA and it works great thru 4.7.x.

Thanks, will try this out.

Fix documented in https://scribu.net/wordpress/front-end-editor/common-mistakes-in-themes.html

Need to update your theme to use the_title_attribute() call in theme.

Using IE 8.0.7600.16385 on Windows 7.

Clicking over to the home page produces an immediate “Stack overflow at line: 8” error in Javascript when page loads. Works fine in Firefox 3-4.x.

If I click OK, I can proceed to edit sidebars, titles, categories, content. The floating menu sometimes lags away off screen in top corner somewhere. Initially it was not appearing at all, like it was lost, but may have been a memory leak/screen size/browser issue.

I’d expect that the Super Admin would have full access to define the ruleset/limits, while individual site admins would have the reporting/status information available. Since reporting on attacks could be filtered on a per-blog basis, that should be a little easier to deal with, and access to admin settings only need to be allowed for the Super, so no immediate hassles of multi-instance settings (yet).

I’d also guess that for reporting, emailing a notification when # of reporting events are over XX, or when any single event rates over XX value would be good – provided the email uses a link to admin + highlighted event/log (emailing individual attacks just doesn’t scale, espec. under WPMU).

Kinda slammed at the moment, I may get a minute to peek at it in the next month, maybe. Haven’t looked into the code, but had looked at PHPIDS before. Big value is having a gaggle of exploit-specific rules ready at runtime.

Typically, when possible, I prefer to apply solutions at the server/Apache level instead of WP, but in this case, I won’t have permissions/access to either of those (this time).

What were the major issues you had noted regarding WPMU?