WebLogin 1.0 - problem after upgrade to 0.9.5

I’ve just upgraded my site to 0.9.5 and moved servers (as recommended) to where register_globals is off. The WebLogin script no longer remembers the page URL after successfully logging in.

For example:

1. Enter the URL www.mysite.com/protectedpage
2. Redirected to login page.
3. Successful login.
4. Redirected to www.mysite.com/anotherpage

In version 0.9.2 the visitor was correctly redirected to www.mysite.com/protectedpage.

I assume the page www.mysite.com/anotherpage is specified as a default login page, but can’t find where (the "Login Home Page" field on the "user" tab of "web user" is blank).

Any suggestions? I’ve trawled the forums without success.

, where `xx` would be the document ID of the page you want the logged in user to be sent to.

# Params:
# &loginhomeid - (Optional)
# redirects the user to first authorized page in the list.
# If no id was specified then the login home page id or
# the current document id will be used
#
# &logouthomeid - (Optional)
# document id to load when user logs out
#

&loginhomeid has not been set.

I think what garethf is getting at is that the behavior is inconsistent to the previous release, which would take you back to a protected page after logging in.

That’s right. It used to work exactly as described:

1. Enter the URL www.mysite.com/protectedpage
2. Redirected to login page.
3. Successful login.
4. Redirected back to www.mysite.com/protectedpage

I’m finding now that everyone, regardless of their permission level, is being redirected to one page (which they may not have permission to access) - it’s as if &loginhomeid had been set.

Gareth.

Sorry - my mistake - &loginhomeid had been set (I use two log in forms).

The redirect back to where you came from doesn’t work through.

Ok, I’ve done some more testing.

I’ve set up a log in form ("www.mysite.com/login") without a default login page (loginhomeid is omitted).

I’ve set up a user ("myuser") without a "Login Home Page"

I’ve set up a page ("www.mysite.com/protectedpage") that’s protected and belongs to a group of pages to which "myuser" has access.

1. "myuser" enters "www.mysite.com/protectedpage" as a URL in his browser.
2. "myuser" is redirected to "www.mysite.com/login".
3. "myuser" correctly enters username and password.
4. "myuser" remains at "www.mysite.com/login".

In MODx 0.9.2, "myuser" would have been redirected to "www.mysite.com/protectedpage".

Please see bugs #548 and #773.

Thanks OpenGeek, that’s useful.

However, my scenario involves neither a logout nor a 401 response page. Would register_globals have any influence?

Actually it does involve a 401. Anytime you access a protected resource, it now returns a 401 response by forwarding the request to the designated error page with that header response. Previously it redirected using a 302 OK response, which is incorrect according to the standards. The solution will be to capture referrer data in the session and then utilize this in the WebLogin snippet to redirect to the referrer on successful login.