Return 200 for all logout requests#42
Return 200 for all logout requests#42cheddar merged 10 commits intotidepool-org:masterfrom amargherio:master
200 for all logout requests#42Conversation
… since the session no longer exists if the verifyToken() comes back bad, there's no reason to return a client error response.
…dify test cases to fit new status code returns.
|
You are right about 201/200. I had originally said 201, just because I am used to POST requests returning 201, but this is a 200 case. |
lib/userapi.js
Outdated
There was a problem hiding this comment.
It's possible that this code also generates a non-200 response. We also are not logging errors. Can you add some lines to log an error if it exists (there should be a log object available in the userapi.js file already) and also to log if we get a non-200 from the deleteToken call?
Then just switch this to a blanket
res.send(200);
return next();
|
Will do. I also wanted to look into adding some sad path test cases for the status codes returned from logouts, although I don't know that there would be a significant benefit from having them. |
|
More test cases are rarely a bad thing :). Btw, I forgot to mention, but welcome and thanks for the contribution! There's gonna be one bit of administrative thing that we are going to have to do before we can accept the contribution as well: get agreement to a CLA. Here's the canned text for that ;). Before I can merge the pull request, we need you to agree to our CLA. You can find the CLA at http://tidepool-org.github.io/TidepoolCLA.pdf. If you are working on your own behalf and agree to the CLA, responding here with a comment of "I agree to the terms of Tidepool Project's Contributor License Agreement as it exists at http://tidepool-org.github.io/TidepoolCLA.pdf on " is sufficient. If your contributions are on behalf of a company, can you have your company fill out the corporate CLA and submit it to us? |
|
Hi Adam, just as Eric said welcome and thanks for thanking the time to help us out. Cheers On Fri, Apr 25, 2014 at 6:57 AM, cheddar notifications@github.com wrote:
|
|
Fair enough. It might take me a bit to get some good test cases setup (never done pure Javascript development before - coming from a Java/Scala/Go/Ruby-ish background) but I'll see what I can do. Thank you for the warm welcome! I'm actually a T1 diabetic, so something like this hits close to home for me. I've been considering giving a Dexcom a try, and with that, thinking about tooling I could put in place to help me manage the data side a bit better. After hearing about this, I decided I wanted to try to contribute as much as I can. As for the CLA, since I'm working as an individual - I agree to the terms of Tidepool Project's Contributor License Agreement as it exists as http://tidepool-org.github.io/TidepoolCLA.pdf on April 24, 2014. I've also been in and out of IRC as MarioEIU. |
|
I come from the same background (actually, a lot more Java than anything else ;)), also T1D (most of us are), no worries on the time. If you want, I'd merge it just with the changes to logging and making it consistent. Can leave the unit tests for a follow-on. That's always a slippery-slope though ;). If you think you'll have time for the unit tests, great, I'll wait. If you think that something might get in the way, then let's just get the functionality in and leave the unit tests. Great to have you! |
lib/userapi.js
Outdated
There was a problem hiding this comment.
I don't remember if the rest of the code here uses truthyness, but in general I think we should try to stay away from it as much as possible
err != null
Is what should be here instead.
lib/userapi.js
Outdated
There was a problem hiding this comment.
Much like log4j, et al, our logger understands error objects and handles them specially, it's actually best to put the err first, as in
log.warn(err, 'Unable to verify token.');
There was a problem hiding this comment.
If you change this line to what I have and fix it for the deleteToken call too, I'll go ahead on merge. Sorry for the back and forth.
|
@amargherio One very last little bit of stuff. Sorry the logger stuff wasn't that explicit (the lack of function signatures makes it more difficult...) Also, when you push the next bit of code, could you comment on the PR? It took me a while to realize that you had done more even though you had actually asked about it in chat... |
|
@cheddar thanks for the additional comments on the commits. that's my inexperience in javascript shining through. this most recent commit should pass the travis build. |
Return `200` for all logout requests
3 participants
This commit should address #33 (/logout never needs to return 401). I'm still kinda new to Javascript, but I'd really like to be able to contribute to this project. If any changes need to be made to this PR, please let me know!
As an aside - should the requests be returning 201 or 200? 201 indicates that a new resource has been created while 200 just indicates success.