Hello Russ, yes, I want to prefilling field from cookie, thanks for your suggestion, I will take a look at it 1
-- Yang Orange Key: 35745318S1 On Wed, Jan 9, 2013 at 8:26 PM, Russ Allbery <[email protected]>wrote: > YANG ChengFu <[email protected]> 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 <[email protected]> > Technical Lead, ITS Infrastructure Delivery Group, Stanford University >
