opinion -- modal login not what it could/should be

[weheh]

After much tinkering with modal login, I'm formulating the following
opinions:
- modal login is a powerful and useful capability
- modal login is not well supported by web2py and not at all a
functionality that newbies would be able to implement easily. As per
pbreit in http://groups.google.com/group/web2py/browse_thread/thread/1394315562b1bba0/729729e02bdba61f#729729e02bdba61f,
if you use modal login you run into troubles elsewhere when you need
to point to a login url. For instance, if you decorate with
@auth.requires_login(), then you're going to run into trouble. That's
because you'll be redirected to a login page, which doesn't exist.
- the implementation of auth does not natively support components.
This requires a workaround -- intercepting the login completion with
auth.settings.login_onaccept and raising an HTTP call. However, it
seems as though _onaccept is not uniformly implemented throughout
auth.

I believe an experienced user can workaround these issues. However,
with the rise of components and jQuery interactivity, I think it's in
the community's interest to revisit auth and see how it can be
improved to support these new web2py and jQuery capabilities. What do
you think?

[Anthony]

After much tinkering with modal login, I'm formulating the following
opinions:
- modal login is a powerful and useful capability
- modal login is not well supported by web2py and not at all a
functionality that newbies would be able to implement easily.

Sorry, I keep forgetting about auth.login_bare(): http://web2py.com/books/default/chapter/29/9#Manual-Authentication. That might be a better way to go when implementing something like a modal login. You can control all the logic regarding displaying the login form, submitting credentials, returning responses, etc., and just use auth.login_bare() to check the credentials and update auth.user upon successful login. Then you don't have to worry about working around the automatic redirects in auth.login().

 For instance, if you decorate with
@auth.requires_login(), then you're going to run into trouble. That's
because you'll be redirected to a login page, which doesn't exist.
- the implementation of auth does not natively support components.

This can get tricky. When the browser requests a URL that happens to be decorated with @auth.requires_login(), it may be requesting a full page (i.e., not just an Ajax response), so the action has to return a full page. If the user isn't logged in, what page should be returned in that case (given that there is no dedicated login page)? One option might be something like this:

auth.settings.login_url = URL('default', 'index', vars=dict(login='true'))

Then, on the index page, include some JS that checks the URL query string upon page load, and if it includes "login=true", pop up the login modal.

Another option is to have a dedicated login page in addition to the modal login. Use the modal when the user explicitly chooses to login, but use the login page when you have to redirect from a protected URL. I think that's a fairly common approach.

Anthony 

[weheh]

Hmm, I wasn't aware of auth.login_bare(). Will have to check it out.
As far as decorators are concerned, I have already begun tinkering
with a method like you mention, so we are on the same wavelength about
where to do it. I just have to figure out how. If I redirect to a
URL('default','index'), and that contains a response.js='ajax(blah
blah);', will the response.js get executed or will I need to do the
HTTP(200) trick again?

[Anthony]

If I redirect to a
URL('default','index'), and that contains a response.js='ajax(blah
blah);', will the response.js get executed or will I need to do the
HTTP(200) trick again?

Yes, if you redirect to a particular URL, once the URL is requested by the browser, everything should work as it would have if the URL had been requested directly.

Anthony