IZIVIA/ocpi-toolkit

Credentials Client and Server are deleting TokenB

Closed this issue · 4 comments

atschabu commented

I've been evaluating this library and found an inconsistency with the credentials module. According to the documentation

The Receiver stores CREDENTIALS_TOKEN_B and uses it for any requests to the Sender Platform, including the version information and details

yet it looks like this library is discarding CREDENTIALS_TOKEN_B together with TOKEN_A on successful registration, and is only using CREDENTIALS_TOKEN_C for receiving and sending requests:

ocpi-toolkit/ocpi-toolkit-2.2.1/src/main/kotlin/com/izivia/ocpi/toolkit/modules/credentials/services/CredentialsClientService.kt

Line 108 in 493f347

clientPlatformRepository.removeCredentialsTokenB(platformUrl = serverVersionsEndpointUrl)

Shouldn't the B token be kept, and the credentials include some kind of hint if the platform is either the receiver or sender?

lilgallon commented

Thanks for your feedback, you are absolutely right. The receiver has to use Token B to communicate with the sender. There was also a discussion about that here: ocpi/ocpi#166

So:

  • As a receiver, the token B has to be kept, and the generated token C should not.
  • As a sender, the generated token B should not be be kept, and the token C should be kept.

Then, to know which token to use, there are two cases:

  • The platform only has either token B or token C. In that case, use the one that exists
  • The platform has both of them. Because at some point both systems registered with the other. I am not sure about the solution yet. In that case, the caller knows if the call is made as a receiver or a sender. So I guess that the lib should offer the possibility to choose the token to use for the call. that's completely wrong

In clients, a solution would be to add a parameter that specifies who ou are when you call the other platform:

  • the receiver (in that case use token B)
  • the sender (in that case use token C)
  • guess (use the token that exists, if both exists use token C)

all these statements are completely wrong..

atschabu commented

you always need to keep B and C .. because you need one to verify the incoming requests, and the other to send requests.

I think it might be easier to use something along the lines of 'our token' and 'their token' instead of B / C, as B and C is relative to whether you were the receiver or sender, while Ours and Theirs would be absolute from server / client perspective

This way a server will always compare authorization header against "their token" and a clients will emit "our token"

essentially the registration part would always store the 'received' token (be it B or C) as "our token" and the one it generates and transmits as "their token"

alternative names would be
our token / client token / request token
their token / server token / response token

lilgallon commented

Yes you are right I forgot that part. I really like this approach of storing two tokens, one being ours, and the other one being theirs. I don't know why I didn't think of it... It removes the hassle of picking the right token at the right time.

It will be fixed this in the next version. Thanks again for your feedback

  • 👍1
lilgallon commented

It's fixed in https://github.com/IZIVIA/ocpi-toolkit/releases/tag/R-0.0.14 for ocpi 2.2.1. This version is the priority right now, but the changes will be made on 2.1.1 & 2.1.1-gireve later on

  • 🎉1