Forum OpenACS Development: Re: HEAD redirect to registration behavior is different/broken
The script goes in /www/register/user-join-custom.tcl
Still the same problem?
And why does it work if we call ad_require_permission?
Strange.... Really strange.....
I really think this is rooted in a change of philosophy regarding what to do with a set of unrecognized credentials.
As Lars explains (see the bugtracker thread), on a production site, it gets really messy when a registered user mistypes or enters an unknown (possibly valid to the user) email when asked to identify himself. The old (pre 5.0) system behavior was to immediately redirect to the new user registration page. Lars says that in _many_ cases, the user continues and registers a new email address. This is not a good thing and I agree that this should be discouraged.
The 5.0 behavior was changed to _not_ redirect to the new user registration page. It is intended to make the user pay attention, and it probably serves that purpose well. In order for a new user to register at this point, he has to click the register link. This is where a problem arises, for two reasons:
- A new user is now required to explicitly click the register link, and IMO the register link is not prominent.
- When the new user follows the register link and completes registration, he is not redirected to the page that initially required authenticated access. He's virtually "lost" So, the user that I'm trying to lure (maybe a bad word here) painlessly into my site just hit two LARGE roadblocks. OK, maybe one small and one large...
Maybe we can't do much about the explicit "register" click except to make the instructions and UI easier to use - possibly two large square graphics or buttons side-by-side that really make it clear that you can either RE-ENTER existing account credentials, or REGISTER FOR A NEW ACCOUNT. We should require an explicit click to proceed down either of these paths. Make the choices prominent and equal.
No matter how the UI is handled, the return_url _must_ be carried through however many clicks it takes to get authenticated, and the end result of this sequence _must_ be to place the user in the location he initially requested.
- I accessed http://192.168.16.1:8000/dotlrn/classes/segeln/asc/asc
- I got redirected to http://192.168.16.1:8000/register/?return%5furl=http%3a%2f%2f192%2e168%2e16%2e1%3a8000%2fdotlrn%2fclasses%2fsegeln%2fasc%2fasc%2fapplets
- I clicked the register link that brought me to http://192.168.16.1:8000/register/user-new?return%5furl=http%3a%2f%2f192%2e168%2e16%2e1%3a8000%2fdotlrn%2fclasses%2fsegeln%2fasc%2fasc%2fapplets
- I filled out the details and got redirected to http://192.168.16.1:8000/dotlrn/classes/segeln/asc/asc
Please try it out with the latest checkout and if it is fixed, just close your bug again. If not, I'm really curious what is different between our setups.
When you get the initial redirect to the login page, enter a new set of credentials and hit ENTER. You should see an error indicating unknown user. This step should be inserted between 2 and 3 in your numbered list above.
Now, click the register link
where are you redirected upon completion of registration?
I haven't added or changed any of the pages that process the new-user.
The minimal example I included above goes into /www/register because the system treats return_url differently if you're entering along that vector. However, it's not required to illustrate the problem.
Can you give me a url (that I can reach) to a page requiring authenticated access on a 5.0 server? Once authenticated, the page should be displayable without requiring membership in any special groups. I'll try to reproduce this issue and give you the exact blow-by-blow click sequence so you can reproduce it also.
We could probably just pick Yahoo's login screen and snatch a few good ideas from there.
Could you file a bug for this, please?
I filed a separate bug against the login/register UI at
Thanks for all your assistance.
a) verify on the automated test servers,
b) help us track down where the return_url gets lost for you:
- is it present in the URL on the original login page?
- is it present in the register-link on the login page?
- is it present in the register-link after you get the same page back with the 'invalid login' message (if you do that).
- is it present in the user-new form? (view source)
I've been testing using a page request of /register/user-join-custom.
In going through Lars' request above, it appears that his initial changes to pass the return_url through the register links *has* fixed the problem in cases where the page requested is not under /register. This is odd.
It's no wonder that you aren't able to reproduce the problem at this time. We are looking in different places, and the results are not consistent across all requests.
So, using /register/user-join-custom, the answers to your questions above are:
b1) return_url is NOT present in the URL of the initially displayed login page (it WAS contained in the URL when a non-"/register/..." page was requested)
b2) return_url is present in the register link on the initially displayed login page, but it is WRONG. Instead of containing /register/user-join-custom, it contains /pvt/home. The correct value was contained in this link when a non-"/register/..." page was requested.
See? I'm really not crazy...
Thank you, Lars for being the one to step back to look at the 30,000 foot view and re-evaluate and re-establish conditions.