Implement accountAdmin.sessions.add(options)

[gr2m]

Implement accountAdmin.sessions.add(options)

[ransomw]

i've started on this. here are some notes/questions

git disclaimer

before going any further, please don't be alarmed by the git history, L70-72 of admin/index.js, or any other sloppiness in the linked sketch. i'm still figuring out git workflows appropriate for these tasks and erring on the side more commits. i'll rebase, etc. before a PR.

nock is awesome!

really glad i took a look at this issue if only for the sake of learning of this lib. answers so many questions about how to do integration testing.

generating fixtures from hoodie-server or elsewhere?

i pretty much pattern-matched the new fixture (not that the placeholder implementation is using it, anyway) and have no idea what the couchdb/hoodie-server wire protocol looks like. i wonder if it might be a good idea to curl hoodie-server to generate test fixtures? or is there a link to documentation? or more generally, how were the existing fixtures created?

plans for tests

most of the questions here revolve around how to wire up the fixtures. i guess i ought to use the existing accounts.json to test for the NotFoundError error condition**?**

plans for implementation

i was thinking about making calls to the admin.accounts interface from the admin.sessions.add() implementation in order to, for example, see if a user account exists. is this reasonable, or will the server give enough error information to reject w/ a detailed error**?**

... kind of returns to the "generating fixtures" question, i guess.

misc

thanks for you time. i'm learning a lot and hopefully will catch up on the irc soon.

[gr2m]

Weclome back @ransomw 👋 we must have missed to invite you to the HoodieHQ Contributors team last time, I fixed that now, you should receive an invitation :)

Could you start a pull request? That will make the discussion simpler I think. Don’t worry at all about the commits, most of the Pull Request have been a huge mess before we cleaned them up ahead of the merge, yours is totally normal in that regard :)

You can take fixtures from the specification here: http://docs.accountjsonapi.apiary.io/ – but I just realised we have no specification to create a session for a user. Sorry for that, we should have realised that before creating the issue.

I’d suggest we add this route that you can build the feature against:

POST /accounts/{id}/sessions. The request has no body, we don’t need to send a username because the account is clear, and now password because it’s a request by an admin. The response looks like this:

{
  "links": {
    "self": "https://example.com/accounts/abc1234/sessions/sessionid123"
  },
  "data": {
    "id": "sessionid123",
    "type": "session",
    "relationships": {
      "account": {
        "links": {
          "related": "https://example.com/accounts/abc1234"
        },
        "data": {
          "id": "abc1234",
          "type": "account"
        }
      }
    }
  }
}

This might change as we need to discuss it for the spec, but if it does we can make a follow up issue to adjust your implementation.

Does that work for you?

[ransomw]

wow, thanks much for the quick reply! was afk for a moment.. yah, we can move discussion to a pr thread.