Timeline for Token based authentication and multiple sessions
Current License: CC BY-SA 3.0
26 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 14, 2017 at 4:10 | comment | added | user2727195 | hey @genichm revisiting this thread, a little update, I'm using jwt.io, creating a token with payload and sending it back to the client, and then I verify and get the data back, this way I don't have to use redis or memcache, please advise. | |
| May 27, 2015 at 6:35 | comment | added | genichm | Usually if I want to create some JSON represented as string I use JSON.NET serializer or protobuf-net as binary serializer. Here you can find supported by Redis data types redis.io/topics/data-types | |
| May 27, 2015 at 6:21 | comment | added | genichm | This way it will work: set "somekey" "{\"_isAdmin\":true}" in try.redis.io. In Redis on my computer this works too "somekey" "{\"_isAdmin\": true }" - with spaces before and after true | |
| May 27, 2015 at 0:04 | comment | added | user2727195 | OR I should be using hashes? | |
| May 26, 2015 at 23:56 | comment | added | user2727195 | I guess, key=>value type only accepts single value, for instance SET connections 10, I can't execute the command set "somekey" {"_isAdmin": true } (tried on try.redis.io) unless I use hashes, I was using key/value to lookup users via tokens (multiple tokens) | |
| May 18, 2015 at 6:31 | comment | added | genichm | Now you know who is the users, is that user admin and administration roles of the user or any information you need to know about the user. And it may be done in any route not only /admin. | |
| May 18, 2015 at 6:26 | comment | added | genichm | key:admin may work, but it is strange to me to store data about user in key even on server. Usually required a little bit more information about user than to know admin or not. So all that information maybe stored in value. For example value may be information that looks this way {"_isAdmin":true, "_roles":[1,2,3], "_firstName":"John", "_lastName":"Doe"}. When the key received you trying to retrieve value by this key, if nothing exists that user not logged in, if data exists you deserializing that data into some object, and from that moment holds all required data. | |
| May 17, 2015 at 19:12 | comment | added | user2727195 | the authentication system is shared between the client and the server, so if route is /admin I check if key:admin exists (on the server, not client), I'm wondering if key:admin is good or is there a better way | |
| May 17, 2015 at 19:09 | comment | added | user2727195 | ah, let me clear, I'm not storing user_id at client, client only has the key. Let's say client saves the key 'abc'. On the server (nodejs) I'm saving 'abc:admin' => 101. and for standard user 'xyz' => 102 | |
| May 17, 2015 at 19:02 | comment | added | genichm | May be I am did not understand right, only to emphasize, It is prohibited to store any user data related to login on client except of some key that should not include (again) any login data or user role and etc... All data of this kind have to be stored on the server. So the strategy can be - to store key / value pair where the key some login key that user got from the server and value is user data. User sends you key in all requests and you retrieves user from Radis on base of this key. Which language do you use for programming? Maybe I can show you some code or pseudo code. | |
| May 17, 2015 at 17:45 | comment | added | user2727195 | another question man :) I've both admin and standard users (only key/value pairs no hash), the authentication system is same for both. For admin authentication, I'm setting the key as key:admin = user_id, and for standard user key = user_id, to avoid letting the standard user, if he's logged in already to access the /admin pieces, that's all I can think of, any better strategy? | |
| May 15, 2015 at 0:34 | comment | added | user2727195 | awesome man. Thanks for your input, it has been helpful. | |
| May 14, 2015 at 3:33 | comment | added | genichm | And even with relational databases it can be quick response times, for example at this moment I can find posts by tag or list of tags in table with 20 million records in less than 50 milliseconds. With filter by 1 additional parameter that is list too and order by. | |
| May 14, 2015 at 3:30 | comment | added | genichm | I have configured lifetime fot 2 weeks cause in our particular case it was the maximum. But it is really depended on project. You can not stay without database, it still will be the main data storage especially when exists so many data like in twitter. I believe that they loading partially data to memory when user connected, but all data saved in some database. | |
| May 13, 2015 at 20:52 | comment | added | user2727195 | also I've a feeling that sites like for example twitter are storing everything in the redis, following, followers including posts. Is that the way everyone's heading right now and not using database anymore? | |
| May 13, 2015 at 20:40 | comment | added | user2727195 | I see, and how much time did you configure the lifetime for the key in your last project? | |
| May 13, 2015 at 17:24 | comment | added | genichm | For example somebody can to reinstall application on iOS without logout, deleting browser cache, using different browsers on same computer. It always exists ghost keys no meter what you do. But if you configure lifetime of the key in redis you can solve this problem (at least partially). In my last project I am extending this lifetime every time user starts session on the site. It means that if user not browse to the site for some period of time login token deleted from redis automatically. On iOS for example you can send renew command each time user opens program. | |
| May 13, 2015 at 16:33 | comment | added | user2727195 | however, in your earlier comments when you said ghost keys, scenario 1 -> iOS app is logged in all the time, if logout I'll delete the auth key on redis, same with browser end. save the token in local storage and renew when website was accessed to ensure login validity. my question is when is the case when I'll end up with too many ghost keys? | |
| May 13, 2015 at 16:30 | comment | added | user2727195 | Thanks man for changing my whole perspective about things, I learned redis and changed my nodejs code overnight, and all my token based authentications are going through redis. Only hitting the database for username/password. auth validation responses are amazing under 10ms, managing authToken in the db was pain, for every renew of token, I'm deleting the old one (learned from twitter toy clone in php) | |
| May 13, 2015 at 3:13 | comment | added | genichm | Device id for example can show you how long user uses your program from same device, or how many devices has the user. In REDIS you can store data this way - key is your authtoken and value some complex data about the login. It may be some data like device id, user first name and... Value can be stored as, for example, json string that you can deserialize or some binary data. It may work this way: request coming -> get authtoken from that request -> find record in redis by authkey -> if record exists deserialize value. Then on output you will hold base data about user without querying database | |
| May 12, 2015 at 23:23 | comment | added | user2727195 | I'm studying more on REDIS, and going to implement it, can you please help. so I'm going to have authToken, user_id as key value pair, tokens['abc'] = 1, tokens['def'] = 2, tokens['xyz'] = 3, wondering where device_id comes in this picture for the key/value pair | |
| May 12, 2015 at 21:19 | comment | added | user2727195 | question, what do I use device_id for when it comes to statistics? it's going to be some guid that I won't be able to understand, second do I've to check on the server that both device_id and token matches to retrieve user_id | |
| May 12, 2015 at 20:46 | vote | accept | user2727195 | ||
| May 12, 2015 at 20:03 | history | undeleted | genichm | ||
| May 12, 2015 at 19:16 | history | deleted | genichm | via Vote | |
| May 12, 2015 at 19:16 | history | answered | genichm | CC BY-SA 3.0 |