6 ms·

I don't really understand what the service worker that makes an extra network request adds here. Why not just have the code that validates the session just do

by azdle 10y ago

I don't really understand what the service worker that makes an extra network request adds here. Why not just have the code that validates the session just do an `if (short_session != valid) { lookup_long_session_in_db() }` then return a fresh short session cookie with whatever request you're currently handling?

edvinbesic 10y ago
Pretty much this. Especially if you are already using promises in your library, having an async function that returns the token to you solves that problem. Now you don't have to worry about where your token comes from, if it immediately resolved or if it had to do a round-trip to refresh the token etc.
mark242 10y ago
That's the other option; sending both session cookies at the same time and having the server do the work. Google's solution pushes that "if (short_session != valid)" logic to the client vs having it run on the server.
adregan 10y ago
The benefit of the service worker is that they can intercept all fetch events and would allow you to move validation code out of the thread that is running the UI. It can make for a simpler client, but really it's just shifting the complexity to another layer. However, there are a lot of potential benefits to service workers (eg. caching, background downloads, notifications—tho possibly a negative) so perhaps the added complexity is ok.
- azdle 10y ago
  Right, but I'd really doubt that "store new auth token if it exists in response" would take long enough that it causes any kind of problem. I know that there are benefits to using service workers in general, I guess I was just thinking about it in terms of adding a service worker to an application that isn't currently using them just to do the handshake they're suggesting. In which case it would be a lot of added complexity and wouldn't work across the board, whereas doing the check on the server side would add very little complexity and would work with every browser made since about 1995.
dpark 10y ago
1. This assumes that every page you might make the request to can issue auth tokens. This might be fine for small sites where auth isn't a concern (but then just issue a long-lived token and don't bother with all this), but for larger sites, capability to issue auth tokens is generally isolated from the rest of the services. 2. Your pseudo-code returns a legitimate short session cookie in response to gibberish. I'm hoping that this is just because you elided a lot of detail.
- azdle 10y ago
  1. Why does every end-point being able to refresh a token (or whatever you want to call it) imply that auth must not be a concern? I will fully admit that I've never worked on really large scale web services, so hopefully that's not a super obvious thing. I would think that having all pages be able to handle auth is just a architecture question. Maybe I've just been too deep for too long in writing a webserver in Iron [0], but the way you handle auth in it, by using middleware and wrapping any endpoint that needs auth with an auth handler, makes doing something like this trivial. 2. Definitely left out a lot, I mean it doesn't really return anything at all. Just meant it as some shorthand pseudo code to make explaining it shorter. :) [0] https://github.com/iron/iron https://github.com/iron/iron EDIT: Actually now I'm not sure if you're talking server-side or client-side, but I think the argument still stands. I was assuming auth "tokens" could actually be cookies, but even if not, your API library just needs to have a check to see the the request returned updated auth. It's still just in one place, handled in all calls, rather than just the single call that would otherwise handle it.
  - dpark 10y ago
    I was referring to server side. If you're really serious about security, you probably want to isolate the login process to a dedicated server. If your web server is breached, do you really want your auth keys leaked? And do you really want access to your user's creds available en masse to the breached server? If you're running a small scale service, you're unlikely to build a dedicated login service. If you're running a large scale service, you probably should. Edit: Based on Thomas's answers here, I am wrong about this, so I guess take my thoughts with a grain of salt.

by azdle 10y ago

edvinbesic 10y ago

Pretty much this. Especially if you are already using promises in your library, having an async function that returns the token to you solves that problem. Now you don't have to worry about where your token comes from, if it immediately resolved or if it had to do a round-trip to refresh the token etc.

mark242 10y ago

That's the other option; sending both session cookies at the same time and having the server do the work. Google's solution pushes that "if (short_session != valid)" logic to the client vs having it run on the server.

adregan 10y ago

The benefit of the service worker is that they can intercept all fetch events and would allow you to move validation code out of the thread that is running the UI. It can make for a simpler client, but really it's just shifting the complexity to another layer. However, there are a lot of potential benefits to service workers (eg. caching, background downloads, notifications—tho possibly a negative) so perhaps the added complexity is ok.

azdle 10y ago
Right, but I'd really doubt that "store new auth token if it exists in response" would take long enough that it causes any kind of problem. I know that there are benefits to using service workers in general, I guess I was just thinking about it in terms of adding a service worker to an application that isn't currently using them just to do the handshake they're suggesting. In which case it would be a lot of added complexity and wouldn't work across the board, whereas doing the check on the server side would add very little complexity and would work with every browser made since about 1995.

dpark 10y ago

1. This assumes that every page you might make the request to can issue auth tokens. This might be fine for small sites where auth isn't a concern (but then just issue a long-lived token and don't bother with all this), but for larger sites, capability to issue auth tokens is generally isolated from the rest of the services. 2. Your pseudo-code returns a legitimate short session cookie in response to gibberish. I'm hoping that this is just because you elided a lot of detail.

azdle 10y ago
1. Why does every end-point being able to refresh a token (or whatever you want to call it) imply that auth must not be a concern? I will fully admit that I've never worked on really large scale web services, so hopefully that's not a super obvious thing. I would think that having all pages be able to handle auth is just a architecture question. Maybe I've just been too deep for too long in writing a webserver in Iron [0], but the way you handle auth in it, by using middleware and wrapping any endpoint that needs auth with an auth handler, makes doing something like this trivial. 2. Definitely left out a lot, I mean it doesn't really return anything at all. Just meant it as some shorthand pseudo code to make explaining it shorter. :) [0] https://github.com/iron/iron https://github.com/iron/iron EDIT: Actually now I'm not sure if you're talking server-side or client-side, but I think the argument still stands. I was assuming auth "tokens" could actually be cookies, but even if not, your API library just needs to have a check to see the the request returned updated auth. It's still just in one place, handled in all calls, rather than just the single call that would otherwise handle it.
- dpark 10y ago
  I was referring to server side. If you're really serious about security, you probably want to isolate the login process to a dedicated server. If your web server is breached, do you really want your auth keys leaked? And do you really want access to your user's creds available en masse to the breached server? If you're running a small scale service, you're unlikely to build a dedicated login service. If you're running a large scale service, you probably should. Edit: Based on Thomas's answers here, I am wrong about this, so I guess take my thoughts with a grain of salt.