Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

#18 implement properties.timeout for account().tokens.add(properties) #43

Merged
merged 24 commits into from Dec 4, 2016

Conversation

vkai
Copy link
Contributor

@vkai vkai commented Nov 27, 2016

closes #18

@vkai
Copy link
Contributor Author

vkai commented Nov 27, 2016

@gr2m the hoodie-account-server-api doc lists under api.account().tokens.add() that the token would store the creation date "createdAt": "2016-01-01T00:00:00.000Z". However, when writing my integration test, I created a token that did not automatically include the "createdAt" property. I ended up adding the property manually for the purposes of the test.

Am I missing something about how the tokens should work?

@gr2m
Copy link
Member

gr2m commented Nov 27, 2016

you are right, the token methods have been added in a hurry as it looks, there seem rather incomplete
https://github.com/hoodiehq/hoodie-account-server-api/blob/82bf25c47839818d4eb73467b8ba500074804f67/lib/utils/add-token-to-user-doc.js

We usually start with a README for a new project and then implement it backwards, so it’s possible that we sometimes miss things. I agree that we need the createdAt timestamps in order for timeout to be useful. I would add it to the add-token-to-user-doc.js itself, instead of adding it test

@@ -15,6 +15,9 @@ function addTokenToUserDoc (db, account, token) {
var id = token.id || uuid.v4()
delete token.id

var now = new Date(Date.now())
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you can leave out the Date.now(), new Date() should do the same thing.
You can also shorten the two lines to token.createdAt = new Date().toISOString() if you don’t use the now variable anywhere else

@@ -13,6 +13,10 @@ function account (setupPromise, state, findAccountOptions) {
return Promise.reject(errors.TOKEN_TYPE_INVALID)
}

if (!tokenOptions.hasOwnProperty('timeout')) {
tokenOptions.timeout = 7200
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I’m sorry I should have thought about this earlier, but can we add another timestamp expiresAt instead of adding a timeout property? It will be simpler to lookup later as we can directly look for that property without any calculation. Or do you see any downside with that approach?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No I agree that would be a more practical approach, as well as more conventional. I'll change it!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you’re the best 🙌

@gr2m
Copy link
Member

gr2m commented Dec 1, 2016

This looks all good 👍 thanks!

Only thing left is to update the README now, where it still says "TO BE DONE" for properties.timeout in the options table for api.account().tokens.add()

@vkai
Copy link
Contributor Author

vkai commented Dec 1, 2016

I've removed the "TO BE DONE" note for properties.timeout as well as properties.type as that was pushed as part of #36 that @Taekyoon and I worked on last.

Copy link
Member

@gr2m gr2m left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey I’m so sorry, I found another bug right now, you put in the check for sessions.add, but we also use the token authentication in other places. I think we should put in the check into find-user-doc-by-username-or-id-or-token.js as it’s used in all the places. Could you make that change, please?

@vkai
Copy link
Contributor Author

vkai commented Dec 2, 2016

@gr2m, no worries, that makes more sense. Long post ahead...

I think I've found a bug that came up in email-verification-test.js#L35 when I moved the expiration check to find-user-doc-by-username-or-id-or-token.js.

account().tokens.find() returns the token "as is" from the userdoc without an id property. When api.accounts.update() is called in email-verification-test.js, there is no id property on token. Follow the code down to find-user-doc-by-username-or-id-or-token.js#L34 and there's no tokenId for the db query.

The test still works because the query would still respond with the userdoc (not sure how that works). Is this by design? This creates a problem because I've moved the expiration check into that snippet:

  return db.query('byToken', {
    key: tokenId,
    include_docs: true
  }).then(function (response) {
    if (response.rows.length === 0) {
      throw PouchDBErrors.MISSING_DOC
    }

    var doc = response.rows[0].doc
    if (isTokenExpired(doc.tokens[tokenId])) {
      return Promise.reject(errors.TOKEN_EXPIRED)
    }

    return doc
  })

tokenId is undefined by this point, and thus I can't check if the token is expired. Does my check make sense there? If that makes sense, then I would change email-verification-test.js to use a preset token id. What do you think?

@gr2m
Copy link
Member

gr2m commented Dec 3, 2016

can you push your current state please?

account().tokens.find() returns the token "as is" from the userdoc without an id property

That sounds like a bug, the id property should definitely be returned. We have to add logic around

where we set the id before returning the doc, I think?

@vkai
Copy link
Contributor Author

vkai commented Dec 3, 2016

I've pushed my current state with email-verification-test.js still failing.

If the id should be returned with the token, that would solve the problem. api.account().tokens.add() works because add-token-to-user-doc.js#L23 adds the id back to the token object before returning. If find() should also return the id, should we be deleting the id property from the token in the first place? add-token-to-user-doc.js#L16

@gr2m
Copy link
Member

gr2m commented Dec 3, 2016

If find() should also return the id, should we be deleting the id property from the token in the first place? add-token-to-user-doc.js#L16

yes, because it would be the same value as the tokens key and there would be a risk for corrupt data where the tokens would be different from the id property of the token

@vkai
Copy link
Contributor Author

vkai commented Dec 3, 2016

I see. Ok then I will go ahead and add the id to the result of find() as well.

Copy link
Member

@gr2m gr2m left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

great work 👍👏

@gr2m gr2m merged commit c941c1d into hoodiehq:master Dec 4, 2016
@gr2m
Copy link
Member

gr2m commented Dec 4, 2016

If you like, you could work on code coverage for hoodie-account-server-api, it’s currently at Coverage Status. Let me know if you are interested, I can put together an issue with some more information on how to do that :)

@vkai
Copy link
Contributor Author

vkai commented Dec 4, 2016

@gr2m sure that sounds great!

@gr2m
Copy link
Member

gr2m commented Dec 4, 2016

@vkai awesome! I made this for you: #46

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

implement properties.timeout for account().tokens.add(properties)
2 participants