The actual extension implementation of authentication is a client-side and it works, however we're splitting responsibilities and this should change as well.
Also, we don't track new users with it too. With the platform, we can be able to register them into our database and retain the data to further events.
Besides that, we do updates instantly to tbp-consumer-api without any type of authentication. Basically anyone can make requests to our server and overrides information. This isn't a problem until now, but it's time to make it work properly.
Effort
Platform
Responsible to handle the authentication and the communication about user updates.
POST /api/v1/authenticate/{provider}
Receives the Stateless Authentication Code provided by the provider (?code=)
Return the new user/settings object with every needed information.
Extension
Minor changes at what will be on storage and only one user object there. The type of authentication will change from token to code:
Motivation
The actual extension implementation of authentication is a client-side and it works, however we're splitting responsibilities and this should change as well.
Also, we don't track new users with it too. With the platform, we can be able to register them into our database and retain the data to further events.
Besides that, we do updates instantly to
tbp-consumer-api
without any type of authentication. Basically anyone can make requests to our server and overrides information. This isn't a problem until now, but it's time to make it work properly.Effort
Platform
Responsible to handle the authentication and the communication about user updates.
/api/v1/authenticate/{provider}
Stateless Authentication Code
provided by the provider (?code=)Extension
Minor changes at what will be on storage and only one user object there. The type of authentication will change from
token
tocode
:Consume API
Will receive an update for each new login on the
settings
partition.This will be the first step for a secure development.