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

YANG ChengFu youngseph at
Thu Jan 10 07:27:34 PST 2013

Hello Russ,

yes, I want to prefilling field from cookie, thanks for your suggestion, I
will take a look at it 1

Orange Key: 35745318S1

On Wed, Jan 9, 2013 at 8:26 PM, Russ Allbery <eagle at>wrote:

> YANG ChengFu <youngseph at> 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>
> Technical Lead, ITS Infrastructure Delivery Group, Stanford University
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the webauth-info mailing list