Search Mailing List Archives


Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

Bypass the Confirm page

Russ Allbery eagle at windlord.stanford.edu
Wed Feb 7 12:31:43 PST 2007


Education Center <mailbox030403 at mail.ru> writes:

> I have question about what is the best way how to bypass the displaying
> of the Confirm page after successful login. My quick and simple solution
> was just add the following line to the <head> statement of confirm.tmpl:

>  <meta http-equiv="refresh" content="0; URL='<TMPL_VAR ESCAPE=HTML NAME=return_url>'">

> Also edit confirm.tmpl to disable any output to web page. So all tags
> have been removed but <TMPL_..>.

Yup, you can do this, and it will work on at least some browsers.

According to the HTTP protocol, we're required to return something from
the same host in response to the POST of a user's password, which is why
there's the confirmation page.  One isn't allowed to return a simple
redirect in response to a POST, even though that would otherwise be
sufficient.

Because of that, we took the route of always showing the confirmation page
for consistency of user interaction between users who are already logged
in and users who have to log in.  It also has some security benefit, in
that users can see which site they're visiting, are aware that they're
authenticated and need to close their browser after they're done, and are
aware that site will receive their identity.

Depending on the context in which you're deploying WebAuth, you may or may
not have the same tradeoffs.  It *should* be possible to make most changes
by modifying the templates, although if you want to return a simple
redirect if the user already has single sign-on cookies, that may require
more changes to the login.fcgi script.

-- 
Russ Allbery <eagle at windlord.stanford.edu>
Technical Lead, ITS Unix Systems and Applications, Stanford University



More information about the webauth-info mailing list