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    

weblogin form username and password autosave

Russ Allbery eagle at windlord.stanford.edu
Wed Jan 9 17:26:39 PST 2013


YANG ChengFu <youngseph at gmail.com> writes:

> as I know webauth does not allow web browser to save username and
> password in weblogin form, I guess it is for security reason, but people
> in our company complain a lot, so I am wondering if it is possible to
> enable it to save username or username/password?

I'm not sure what you mean by saving.  Do you mean the browser support for
saving frequently-used form data, prefilling the fields from a cookie, or
something else?

Obviously, we can't pre-fill the password field from a cookie because that
would defeat the whole point of the cookie lifetime management in WebAuth.
If you want to prolong the user's single sign-on lifetime, the right way
to do that is to increase the lifetime on their Kerberos principals.  That
will be picked up by WebLogin (provided that you've not modified
WebKdcProxyTokenLifetime).

To save the username (but not the password) in a long-lived cookie, you
have a couple of options.  The easiest in terms of avoiding local
customization would be to do this via Javascript in your login.tmpl, but
of course that will only work with browsers with Javascript enabled.  Just
avoid the WebAuth cookie namespace (things starting with "webauth_");
otherwise, you can use any cookie name you want.

The more complex method would be to have the WebLogin code set a cookie
after successful authentication that stores the username and then read
that cookie, if present, to pre-fill the username.  This will require code
modifications to the WebLogin module that you'd have to maintain as a
local patch (at least until I get around to adding it as an optional
feature; it seems like a reasonable one), but not very complicated ones.

If you want to try this route, the functions to look at are
print_confirm_page (for setting the cookie) and print_login_page (for
reading the cookie).  In the former, use $resp->subject to get the
username and, instead of only using $resp->proxy_cookies as the cookies in
the call to print_headers, add in an additional cookie of your devising.
Then, in index, read the cookie from the query and set the default value
of $params->{username} if $q->param('username') is not already set.

Note that this won't work properly if you also have a remapping function
defined that modifies the entered username to something site-specific,
since $resp->subject is going to be the mapped form and not the input
form.  That will be one of the complexities of trying to add this as a
standard feature.

-- 
Russ Allbery <eagle at windlord.stanford.edu>
Technical Lead, ITS Infrastructure Delivery Group, Stanford University


More information about the webauth-info mailing list