Forum OpenACS Development: HEAD redirect to registration behavior is different/broken

Collapse
1: HEAD redirect to registration behavior is different/broken
Posted by Randy O'Meara on 10/14/03 03:40 AM
Up until a couple weeks ago when massive updates to HEAD began in preparation for the 5.0 release, when a non-authenticated request for a page was received, the user was redirected to the login page with a 'return_url' attached to allow the initial request to be served upon successful completion of authenication and login. If the user entered unregistered credentials, the credentials were registered with the help of an additional page that gathered first and last names and password confirmation. When the user submitted this page, he was redirected back to the page that was initially requested (the return_url bread crumb).

That functionality appears to be broken. The non-authenticated request is still redirected to the login page, but when new credentials are entered, the form is re-displayed with an error indication. The user must then click a 'register' link on the form to complete his registration. The return_url is not passed through this 'register' link, and the user is not redirected to the initially requested page upon registration completion.

Maybe the easy fix is to pass the return_url in the 'register' link?

Collapse
2: Re: HEAD redirect to registration behavior is different/broken (response to 1)
Posted by Lars Pind on 10/14/03 07:53 AM
Randy,

Please file a bug report.

/Lars

Collapse
4: Re: HEAD redirect to registration behavior is different/broken (response to 3)
Posted by Randy O'Meara on 10/17/03 03:59 AM
I'm not certain where the problem is, but the basic functionality as it existed still doesn't work. Here's how to see what I'm describing:
  1. logout from the site
  2. browse to some page that requires a registered user by entering the url directly into the browser address field
  3. when presented with the login page, enter an unknown set of credentials
  4. the login form will be re-displayed with an error indication
  5. click the Register link and complete your registration
  6. upon registration completion, you should (old behavior) be redirected to the page that was initially requested (above).
As you should see, you'll land at the new user's /pvt space and the initial page request is lost.

This functionality is important because it allows an unregistered user to follow a link provided to him (say) in an email (invitation) message, register, and land on a page that requires that the requester be registered.

In fact, it would be much smoother if the requester did not have to click the Register link but was instead guided directly to the new registration page (as it has worked in previous releases). Anything to smooth the way for the unitiated is good IMO.

This message is also included as a comment to the bug I filed a few days back.

Collapse
5: Re: HEAD redirect to registration behavior is different/broken (response to 4)
Posted by Randy O'Meara on 10/19/03 06:20 AM
Lars: fresh HEAD checkout ~7 PM PST Saturday...

(a few messages have been exchanged through the bug tracker's "comment" mechanism, but I would like to continue the discussion here since the problem resolution may benefit others searching through the forums. When it's resolved, I'll summarize to the open bug.)

I've whittled the code down to the minimum required to illustrate the problem. The following used to work under both 4.x and 5.x. I turned debug off to make logging clearer.

The following short script goes into the /www/register/ directory. 

#===========================================================
# This is a minimal illustration of the problem:
# the second ns_log is never reached.

set p "user-join-custom"

ns_log notice "$p: before ad_maybe_redirect_for_registration"
ad_maybe_redirect_for_registration
ns_log notice "$p: after ad_maybe_redirect_for_registration"

# more stuff...
#===========================================================

Now, do the following:

  1. logout
  2. request http://yourserver/register/user-join-custom?group_id=552&invitation_code=1 (url vars to illustrate what I'm trying to accomplish)
  3. login as some existing user, or go ahead and register new. The failure occurs either way. I need it to work under both conditions.
  4. after login, you will land in /pvt/home
  5. check your server error log for the ns_log entries and you'll see that the first one appears. The second one doesn't.
Here's what my log shows: 
[18/Oct/2003:20:51:04][20583.1080589904][-conn3-] Notice: ns_getform using encoding iso8859-1 for charset iso-8859-1
[18/Oct/2003:20:51:04][20583.1080589904][-conn3-] Notice: user-join-custom: before ad_maybe_redirect_for_registration
[18/Oct/2003:20:51:18][20583.1081093712][-conn4-] Notice: ns_getform using encoding iso8859-1 for charset iso-8859-1
[18/Oct/2003:20:55:59][20583.1074716240][-sched-] Notice: Swept developer support information for 0 requests (103 nsv elements)
Collapse
6: Re: HEAD redirect to registration behavior is different/broken (response to 1)
Posted by Randy O'Meara on 10/19/03 06:32 AM
Oops. It's probably clear enough, but...

The script goes in /www/register/user-join-custom.tcl

Collapse
7: Re: HEAD redirect to registration behavior is different/broken (response to 6)
Posted by Malte Sussdorff on 11/06/03 12:22 PM
What happens if you replace ad_maybe_redirect_for_registration with auth:require_login ?

Still the same problem?

And why does it work if we call ad_require_permission?

Strange.... Really strange.....

Collapse
8: Re: HEAD redirect to registration behavior is different/broken (response to 7)
Posted by Randy O'Meara on 11/07/03 04:19 AM
Malte,

Same behavior.

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.

Collapse
9: Re: HEAD redirect to registration behavior is different/broken (response to 8)
Posted by Malte Sussdorff on 11/07/03 10:12 AM
Randy, I though I got your problem, but apparently I'm not, as I do not see your problem. Here is what I did:
  1. I accessed http://192.168.16.1:8000/dotlrn/classes/segeln/asc/asc
  2. 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
  3. 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
  4. I filled out the details and got redirected to http://192.168.16.1:8000/dotlrn/classes/segeln/asc/asc
Do you have additional steps after /register/user-new/ ?. Do you use /register/user-new/ in the first place, or are you accessing some other page to register a new user?

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.

Collapse
12: Re: HEAD redirect to registration behavior is different/broken (response to 9)
Posted by Randy O'Meara on 11/07/03 11:16 PM
Malte,

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
complete registration
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.

Collapse
10: Re: HEAD redirect to registration behavior is different/broken (response to 8)
Posted by Lars Pind on 11/07/03 12:33 PM
Randy, I agree that we can make the login page a lot more helpufl, and make the register link more prominent.

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?

Thanks,
/Lars

Collapse
14: Re: HEAD redirect to registration behavior is different/broken (response to 10)
Posted by Randy O'Meara on 11/08/03 12:45 AM
Lars,

I filed a separate bug against the login/register UI at
https://openacs.org/bugtracker/openacs/bug?bug%5fnumber=1107

Thanks for all your assistance.

Randy

Collapse
11: Re: HEAD redirect to registration behavior is different/broken (response to 8)
Posted by Lars Pind on 11/07/03 12:35 PM
Also, since the return_url is carried through for everybody except you, could you please

a) verify on the automated test servers,

and

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)

Thanks,
/Lars

Collapse
13: Re: HEAD redirect to registration behavior is different/broken (response to 11)
Posted by Randy O'Meara on 11/08/03 12:31 AM
Lars and Malte,

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.

Thanks,

Randy