Reputation
1,340
Top tag
Next privilege 2,000 Rep.
Edit questions and answers
Badges
1 13 36
Impact
~83k people reached

  • 0 posts edited
  • 0 helpful flags
  • 127 votes cast
Feb
9
awarded  Popular Question
Jan
14
awarded  Popular Question
Dec
31
comment Tracking online users with a stateless architecture
@CormacMulhall You won't block the client with your solution, but you will block a thread on your server ;) since my database doesn't have a non-blocking driver.
Dec
30
comment Tracking online users with a stateless architecture
@CormacMulhall the reason is that my db is not on the same network. I want to avoid any network latency as possible.
Dec
29
comment Tracking online users with a stateless architecture
this part is wrong : "would you not have to store the new JWT in Redis" => JWT token is only stored on client ( localstorage in my case) , never on server, that s the whole benefit of JWT.
Dec
29
comment Tracking online users with a stateless architecture
@ErikEidt Actually, my client is a mobile app ( ios/android) and a mobile app can't handle any cookies. The only way to store data on this kind of client is with the help of browser's localstorage.
Dec
28
awarded  Yearling
Dec
28
revised Tracking online users with a stateless architecture
edited title
Dec
28
comment Tracking online users with a stateless architecture
So the main drawback of this solution I can figure out is that the client has to store the jwt token after EACH request, to be able to send the potentially provided recent timestamp.
Dec
28
comment Tracking online users with a stateless architecture
The solution I guessed would be : 1) The client logs in. 2) The server generated a JWT token also containing the current timestamp ( date of now) 3) The client stores this token in localStorage so that it sends it to each further request. 4) Few times later, client makes a request sending the passed timestamp contained in the previously stored token. 5) The server, before treating the request, checks weither one day has elapsed between the previous query. 6) if elapsed, server updates database ("recentUserTimestamp") generates a new jwt token with the a refreshed timestamp of now and so on.
Dec
28
comment Tracking online users with a stateless architecture
What is different from my OP ? I stated I want to store this data in an audit table while ensuring a very low hit on the DB
Dec
28
comment Tracking online users with a stateless architecture
I think the exact contrary : stateless promotes exchanging information between client and server without storing anything on the server. What I want to store in database is not a direct result of one of those exchanges. The server does not store information of connection or anything else relative to a particular client instance.
Dec
28
comment Tracking online users with a stateless architecture
Stateless in a sense that there is nothing stored in memory (no Memcache, no Redis etc..).
Dec
28
asked Tracking online users with a stateless architecture
Nov
15
accepted Where should I log in the user based on http session: service or controller?
Nov
15
comment Where should I log in the user based on http session: service or controller?
yes exactly. What I meant is: in every case, authorization part should be master by the service, itself delegating to other specific object(s) managing authorization/dealing with database.
Nov
15
comment Where should I log in the user based on http session: service or controller?
Let's say a service aiming to show video if user has paid. User arrives..be authenticated as being a known user, then the service would CHECK whether the user has the right to access the video (if he paid). So it should authorize or not the user. it's just a conceptual example.
Nov
15
comment Where should I log in the user based on http session: service or controller?
authentication is : user identity authorization: does this well authenticated user has access to this service.
Nov
15
comment Where should I log in the user based on http session: service or controller?
So, if I follow you, in this kind of assistance (with annotations/attributes), you would only deal with user authorization in service layer, and let controller authenticates, passing the User entity to the service layer (or whatever other object). Is it right?
Nov
15
revised Where should I log in the user based on http session: service or controller?
added 1 character in body