Access denied after edit my account with language negotiation is enabled

In step 7, when you're requested to enter the password to edit your account, how do the URL looks?

Without language negotiation, it should be something like user/login?destination=user%2Fxxxx%2Fedit (where xxxx is the user ID). How does it look when language negotiation is enabled in your environment?

Also, how is the URL to edit your account? Without language negotiation, it should be something like user/xxxx/edit. How does it look when language negotiation is enabled in your environment?

Ok, I can see where the problem is. It is _persistent_login_match() invoked from persistent_login_init() that's still coded for D5. This piece of code needs to be rewritten to account for the language enhancements introduced in D6.

I will when I have the time. Probably later today or tomorrow as I would like to provide a stable release for PL in the short time, and that will happen when the queue is empty. We're getting closer... :)

Well, the problem I described in #4 is a different issue. That could be fixed in order to support path aliases when checking for secured pages (defined in PL settings).

The problem here ended up being related to another thing... PL needs to avoid user/login and logout paths during hook_boot() where it check the PL cookie. When language negotiation is enabled with a path prefix, then those URLs may look XX/user/login or XX/logout, where XX is the language prefix. The problem is that during hook_boot(), Drupal has not already normalized the path in $_GET['q'], so PL needs to take care of language negotiation itself when filtering for these paths. Otherwise, PL will enter a redirection loop that ends up being detected by the browser and it shows a WSOD with an error similar to "This page does not redirect correctly", as described in #3.

I just committed a fix for this to CVS. The patch can be downloaded from here. Also, it should be available when the next development tarball is rebuilt, probably during the next few hours, or tomorrow.

I'm setting the issue as fixed. Pleas, re-open if the problem persists. Thanks

Could you please, check if you get any page not found error during the login process?

I suspect a page not found error is breaking the session data PL uses to control the state of the re-login process.

If you get a page not found related to a .js file in the files/languages directory, then we need to find a way to trigger a refresh of these files, maybe editing a language string from the translate interface or something similar.

You may want to look at #338630: Locale is unable to rebuild lost Javascript translation files

I just tested a similar environment, but using Spanish (rather than Traditional Chinese) as my default language. It failed when a file not found error ocurred during the login verification page. It worked as soon as I fixed the missing file.

Another way to fix the problem of the missing .js file was disabling javascript. In that case the browser did not made the file not found request, so it worked with javascript disabled. Maybe you could try disabling javascript and see what happens.

I'm not sure where else to look...

One question: did you have PL installed and working before and the problem started when you upgraded to latest beta or you have started trying PL with latest directly?

Another question: If you look at Administer -> Site administration -> Performance, do you see a message in red that tells "The following enabled modules are incompatible with aggressive mode caching and will not function properly...". Which modules do you see there? Also, do you have caching enabled, page compression, etc in that page?