wheelmap-classic icon indicating copy to clipboard operation
wheelmap-classic copied to clipboard

Migrate authentication_token to API Key

Open schultyy opened this issue 8 years ago • 5 comments

Right now we use a user's authentication_token as API Key. This attribute is provided by Devise and actually used for the login process.

We would like to migrate this into the following scenario:

A user still has an authentication_token but we do not use this anymore to authenticate API clients. Instead we have a dedicated attribute holding a user's API key. Here we are not coupled to Devise and its implementation details but are free to generate API keys in any manner we'd like.

During investigation we also found out that there's already an api_key attribute on the user. It looks like it's used for the widget right now. Before we start with implementation here we need to research if we can consolidate api_key and authentication_token.

schultyy avatar Feb 17 '17 11:02 schultyy

It appears to be that ead9fbb2 already smoothed the way for this change.

schultyy avatar Feb 17 '17 11:02 schultyy

Steps to do here:

  • Migrate values from authentication_token over to api_key (has to be done once)
  • use api_key key field from now on, every time a user has to be authenticated
  • "Reset API key" in Frontend needs to recalculate api_key instead of authentication_token
  • The value of api_key has to be shown instead of authentication_token in the user profile page

schultyy avatar Feb 17 '17 11:02 schultyy

This also might mitigate https://github.com/sozialhelden/wheelmap-privateissues/issues/42

schultyy avatar Feb 20 '17 14:02 schultyy

I found out that I missed one important aspect:

There are users with api_key already set. They probably have the wheelmap embedded somewhere. When we migrate authentication_token to api_key these users' embeds won't work anymore. If we just keep api_key and discard authentication_token then mobile users would be required to log in again in their apps. In either way this change would affect a considerable number of users.

Another point is, suppose we consolidated api_key and authentication_token a user getting a hold of the key used for the embed then could also perform write actions. This is something which should not be possible. Instead it would make sense to grant specific rights to certain keys, e.g. "With this key a user is only allowed to read data (used for an embedded map)" or "With this key a user is able to perform read and write actions".

schultyy avatar Feb 21 '17 11:02 schultyy

I'm putting this on hold right now because it became much more complex than first anticipated.

schultyy avatar Feb 21 '17 15:02 schultyy