I am using WORDPRESS 2.7.1 with CAS authentication.
Now I am trying to publish a document on WordPress using XML-RPC but it shows error.
javax.faces.el.EvaluationException: Exception while invoking expression #{org_alfresco_module_blogIntegration_BlogActionListener.executeScript}
caused by:
org.alfresco.module.blogIntegration.BlogIntegrationRuntimeException: Failed to execute blog action ‘metaWeblog.editPost’ @ url ‘
caused by:
marquee.xmlrpc.XmlRpcException: The XML-RPC response could not be parsed: org.xml.sax.SAXParseException: The element type “address” must be terminated by the matching end-tag “”.

I want to know whether XMl-RPC request on wordpress is allowed after applying CAS authentication on WORDPRESS?

Please help.

The secure-admin plugin by wordpress.org also does a great job of implementing SSL within WordPress. I had problems making it work at first and had to debug it to find it was a code error. I’ve made the fixed file available here:

http://haris.tv/2007/01/11/wordpress-ssl-plugin-secure-admin-patched-and-working

Haris

I wish a patch for securing WordPress was included in the WordPress code. Seems such a pity that such a pretty blog engine requires patching to secure.

WordPress 2.03 is a critical security release. It eliminates the HTTP Referrer check and replaces it with a nonce system. What is a referrer check? Well, it is an attempt to confirm that an administrative action is being taken by an administrator in…

I’ll enable it again (with a check for SSL) in the next version of the patch.

Das neue WordPress Widgets Plugin ermöglicht es benutzern, die Sidebar des Blog per Drag´n Drop zu gestalten. An sich eine ziemlich coole Sache, allerdings bleibe ich doch lieber dabei die Sachen per Hand zu editieren. Nicht zu letzt, weil das Wi…

Your patch disables the XML-RPC interface to WordPress. While this is certainly desirable if you’re using XML-RPC over HTTP, there’s no reason you can’t configure your XML-RPC client to access WordPress’ XML-RPC over TLS/SSL. I’ve tested it with both MarsEdit’s and ecto2 and it works fine. Am I missing something or were you just trying to protect against someone inadvertantly using HTTP when they wouldn’t realize they were doing that?

Also, I have WordPress working with lighttpd over HTTP and HTTPS under OS X. If anyone’s struggling with this particular combination, give me shout at ‘ddp at electric-loft dot org’.

No, I haven’t submitted the patch. I doubt it would get accepted, it depends on too many external things. (I’ve submitted a few fixes for bugs I found while working on the patch though.)

IMO WordPress needs proper built-in HTTPS support. Unfortunately the developers seems to a have different take on that. There’s on old feature request which didn’t get much attention. The link to the secure-admin , which was added today, looks at least a bit promising.

Have you contacted the WordPress developers regarding what your patch does? In the control panel (trunk perhaps) they could add an option to secure the administration area only via SSL which would enable your changes.

I’m sure a bit more work than that would be needed, but it would be a great feature to add.

1) Open wp_config.php in your favorite editor:
After the line “require_once(ABSPATH.’wp-settings.php’);” add:

wp_cache_set("siteurl_secure", "https://www.example.com/path-for-wordpress-on-secure-server/", "options");
wp_cache_set("home", ($_SERVER["HTTPS"]?"https://":"http://").$_SERVER["SERVER_NAME"]."/your-blog-path", "options");
wp_cache_set("siteurl", get_settings("home")."/your-web-path-for-wordpress", "options");

This way the settings cache is populated on every call with your values – depending on wheter you hit the site with http or https. The Hostname will be set automatically.

Now, to force logins with SSL, open wp-login.php and search for “case ‘login’:”. A few lines down in the file you’ll find the HTML-head. Right before the add the line:
“>

Once you entered the SSL-site, you will continue to browse it via SSL and vice versa.

Disclaimer: I’ve only modified my wordpress recently, but I did not see any problems arise. But beware: the cookies set on the secure site (if any) would be transmitted via plain HTML unless the hostname for HTTPS is different from the one used for HTTP (which is the case in my setup).

Microsoft Internet Explorer

[OK]

After I click ok, I still see the processing Data… text at the bottom of the list. The link does not dissapear from the list, but if I hit refresh, it is gone. It appears as if the AJAX code to remove the line is failing, but I’m not quite sure.

The reason I want to get the login links to work from the main site is because I’m host several blogs for friends and would like to make the secure login as transparent as possible. Thanks for your help so far.

The reason why using wp_loginout() on the HTTP site doesn’t make sense is that wp_loginout() doesn’t know whether you’re logged in or not because the authentication cookies only get sent over secure HTTPS connections. That means when accesing the HTTP site, you’re always logged out, ie. you’ll always get the ‘Login’ link but never a ‘Logout’ link. When viewing the site over HTTPS the links will work like expected.

Anyhow, it doesn’t hurt. I’ll upload a new patch which always generates https links for wp_loginout() and wp_register() later today.

If I remember correctly that happens if you have the gzip turned on (see the bottom of the Options/Reading page).

mod_proxy_html doesn’t work well with compressed content, so you either have to disable compression completely (I do that on this site) or install the ‘headers’ apache module and uncomment the RequestHeader line in 20-wp2-example.org-ssl (as described above). The latter solution disables compression only for HTTPS requests.

This article says that using SetOutputFilter INFLATE;proxy-html;DEFLATE should work too. But it doesn’t work on any of my systems, maybe because WordPress doesn’t compress everything.

If you’re coming from an HTTPS page, you should get redirected to an HTTPS page — unless some plugin overrides wp_redirect().

Even if the PHP code issues a wrong location for the redirect you shouldn’t get to the login page over plain HTTP. The apache config should deny that request with a “403 Forbidden” error.

You’re right about the login/logout links on non-HTTPS pages though, but that’s an expected consequence of using secure cookies.