[VUFIND-619] "Remember Me" Login Functionality: yes or no? Created: 04/Jul/12 Updated: 19/Jan/24 |
|
| Status: | Resolved |
| Project: | VuFind® |
| Components: | MyResearch, User Interface |
| Affects versions: | 1.3, 2.0alpha |
| Fix versions: | 10.0 |
| Type: | Improvement | Priority: | Minor |
| Reporter: | Filipe MS Bento | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Environment: | if yes, accept cookies in browser must be enabled... | ||
| Attachments: |
Imagem 060.png
Imagem 061.png
Imagem 063.png
Imagem 064.png
Imagem 065.png
|
| Description |
|
Hi! Not so much a new functionally wish, more like a question: is it worth to implement and create a patch for it? "Once a user is authenticated, their credentials are typically stored in the session. This means that when the session ends they will be logged out and have to provide their login details again next time they wish to access the application. You can allow users to choose to stay logged in for longer than the session lasts using a cookie with the remember_me firewall option. The firewall needs to have a secret key configured, which is used to encrypt the cookie's content." * taken from Symfony cookbook, a PHP framework for web projects (what else?... http://symfony.com/). So I guess nothing too complicated to do. Although I'm raising the question if should or not invest my time in doing this for the community, eventually will do it for our own Service, as most of our users and sessions will generated from their own PCs / laptops / smatphones, tablets, whatever... (not from public kiosks). Beside the personal space management (favorites, lists, tags, Library personal data, etc.) being with an active account allows our users (again, not yet in production) to search EBSCOs DBs (in real-time, via EIT), that shows up fully parametized to the current search (and when a search renders in no results found), as Find More EBSCOs Databases (FT) * Academic Search Complete (....) bellow the "Year of Publication" narrow search slider; well, bellow the entire Narrow Search column >> more options to broaden the search to come.. beside the Subject module ( = Author one, with wikipedia’s entries [subjects] and everything else), already implemented and fully functional. So, have you saying: yes or no to "Remember Me" login functionality? Thanks, Filipe |
| Comments |
| Comment by Filipe MS Bento [ 04/Jul/12 ] |
|
<Imagem 064.png> "Explode" a subject, instead of narrow the search (when clicked >> query += "AND <that subject>"), a plain search for that subject... (cont) |
| Comment by Filipe MS Bento [ 04/Jul/12 ] |
|
<Imagem 065.png> (cont) ... with added info from wikipedia when found. This Wiki added info just works for subject "explosions"; other fields explosion just do a plain search (but still have the "See Also" and recommendations at the top... = normal search for that term in a the field to what ot bellongs (from the narrow search entry). |
| Comment by Filipe MS Bento [ 05/Jul/12 ] |
|
When I say "So I guess nothing too complicated to do" is because VuFind already stores a cookie with: PHPSESSID, __atuvc (?), language and ui (at least in the one I'm checking out). Or better yet, a "clean" session: Cookie Information - http://iia.staging.ua.pt/ NAME ui VALUE standard DOMAIN staging.ua.pt PATH / EXPIRES At the end of the Session NAME PHPSESSID VALUE 1kcloq7bkcrmo6eu69snmoirl0 DOMAIN staging.ua.pt PATH / EXPIRES At the end of the Session So I guess it is just a question of change the expiration date (well, include one, not have "At the end of the Session") and include in it an encrypted (is it worth it, I mean being encrypted? --- well, I guess it's better -- search engines do love this kind of stuff) username and a true/false field "remember me". - Filipe |
| Comment by Demian Katz [ 06/Jul/12 ] |
|
This functionality is not as simple as extending the lifetime of the session cookie. In addition to the cookie expiring on the client side, PHP will also expire the session data on the server side if it is not accessed after a certain period of time. I don't think this problem is normally solved by allowing sessions to persist indefinitely. A more common solution would be to create a new database table which associates a token with a user ID. This token is placed in a cookie with a long lifetime on the client machine. When VuFind checks to see if a user is logged in, it would have to do this: 1.) Check if there is currently an active session. If so, use it. 2.) Check if there is currently an active "remember me" token. If so, establish a new session using that data. Obviously in this situation, the user who comes back with the token will lose any short-term information that was only stored in the session (like recent search history). I think this is okay; the purpose of this feature should not be to persist every little detail forever (if we do that, lots of junk will accumulate on the server); it is simply to save the user the trouble of logging in over and over. There are probably some additional complications -- some authentication methods may not play well with the feature (i.e. if they have special logout requirements, weird things may happen if the user is logged in with a token in a way that bypasses the normal login process); obviously security needs to be taken into consideration (how long do long-term tokens live? how are they generated? do we use any extra layers of security like associating an IP address with the token?). So, bottom line: it can be done, but it's not entirely simple. I think it would be a useful feature, but it's not a high priority for me to implement right now. Obviously, if lots of people vote for this, the priorities can be adjusted. |
| Comment by Filipe MS Bento [ 06/Jul/12 ] |
|
Hi, Demian! I think we are not so far apart regarding possible solutions for this; please be aware that it was written in heat of the moment just to get the discussion started (along the others last night). Besides being annoying for a user that uses (sorry about the redundancy) the same point of access to enter their login in every single session, especially if you built features that are only available to them if logged in, there is the security issue of having to enter their password every time, even if in a HTTPS secure environment. If it is a universal one (same for all University's services) the fewer the occasions they are asked to enter it, the better. > do we use any extra layers of security like associating an IP address with the token?) Well, when writing the ticket was also about to include that possibility, but then I thought about the situation I was at that time, logged in to the University’s Computer Center VPN, which gives me a different NAT IP address different every time, as it happens with users that access the net using our campus' wireless coverage (well, all of them). So that solution has to be ruled out. Unfortunately voting is something we don't see so much around here, so have no expectations than to implement it myself when I have the time; a support table that is read every time a session (PHP) is started is a good idea. But I would simplify and just had a new field to the “user” table ("active" or so). If the "remember me" is checked by the user when logging in, just change that true/false field to true and store an encrypted version of the username in a long term cookie (3 months or more). When he/she logs in, it would emulate a normal login (haven't analyzed how it is done in VuFind, but from what I've tried [for a different purpose] it is not just a question of having the session variable “$user” with a value ({assign var=user value="uncrypeted_username_string_read_from_cookie"}, or just signalize that PHP session is validated for that user, instead of an anonymous/proxy one(?). When he/she hits logout, the value of that field, in the "user" table, would be set to false and cookie encrypted username erased (don't have that much experience with cookies, but from the few I had they seem quite easy to handle). Well, if no votes are received I'll get back to this issue when I have the time, because in my opinion is something that our users will sure complain about when entering production, especially because I have placed: {if !$user}{translate text="Have an UU? Login to have access to all functionalities and extra sources"}{/if} at the homepage (/Search/Home) … UU = Universal User (same username/ password for all services … that just receive a token (IUPI) not the actual username and password , so that they can change the username (twice a year) or even better, the password as often as they want without losing access not even for a second to any of the services (if not direct Shibboleth idp (federated identity) some have our own version of it, like Aleph, because at that time, Aleph didn’t support Shibboleth auth/. Btw, UU = e-mail address, official one of the University. Thanks for your thoughts and feedback, Demian, Filipe PS: 0:36am over here and no dinner, so sorry if not so clear in some aspects. EDIT: current structure of "user" table for the ones that don't know it: mysql> desc user; +--------------+--------------+------+-----+---------------------+----------------+ | Field | Type | Null | Key | Default | Extra | +--------------+--------------+------+-----+---------------------+----------------+ | id | int(11) | NO | PRI | NULL | auto_increment | | username | varchar(30) | NO | UNI | | | | password | varchar(32) | NO | | | | | firstname | varchar(50) | NO | | | | | lastname | varchar(50) | NO | | | | | email | varchar(250) | NO | | | | | cat_username | varchar(50) | YES | | NULL | | | cat_password | varchar(50) | YES | | NULL | | | college | varchar(100) | NO | | | | | major | varchar(100) | NO | | | | | home_library | varchar(100) | NO | | | | | created | datetime | NO | | 0000-00-00 00:00:00 | | +--------------+--------------+------+-----+---------------------+----------------+ (sorry, no "system"/fixed font > what a mess!) |
| Comment by Demian Katz [ 09/Jul/12 ] |
|
To mark a user as logged in, VuFind puts a copy of the database object representing the user's row in the session. (In 1.x, I think this is also available as the global $user variable... but in 2.x, it will be more neatly encapsulated in an account manager class -- globals are evil). Regarding your idea of adding a field to the user table and using an encrypted username as the "remember me" cookie, it would work, but I have a couple of reservations: 1.) Using an encrypted value as the cookie is inherently less secure than using a random token. Encryption can always be broken if someone is sufficiently determined, so there's a greater chance of a vulnerability that allows access to arbitrary accounts if the "remember me" token has a built-in meaning. 2.) If you use a random token and a user stores credentials on multiple machines or in multiple browsers, then you can end up with multiple tokens for a single user... that's why you need a separate table rather than a simple flag in the existing user table. Also, regarding remembering IP addresses, I see your point... but perhaps it would be worth having some configurable options for extra layers of verification. Maybe an IP with a subnet mask would cover your use case... or maybe there are other things to examine, like browser family, which could help reduce vulnerability to automated token-guessing attacks. |
| Comment by Demian Katz [ 07/Aug/23 ] |
| See [https://github.com/vufind-org/vufind/pull/3027|https://github.com/vufind-org/vufind/pull/3027|smart-link] |