Comments (4)
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
from ocpi-toolkit.
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
from ocpi-toolkit.
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 existsThe 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..
from ocpi-toolkit.
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
from ocpi-toolkit.
Related Issues (20)
- Request Parameter vs. Owned Object values validation
- DELETE endpoint of Credentials module HOT 1
- Credentials PUT/DELETE methods should return 405 METHOD NOT ALLOWED when the partner is not registered
- If there is an exception, the debug headers are not included in the response.
- Question on the validation of objects HOT 3
- Implement CDR module HOT 3
- Java compatibility
- Module separation HOT 2
- Don't publish annotation-processor & common module to maven central HOT 5
- Credentials sample does not work
- DateTime without the timezone cannot be parsed
- UTF-8 validator only allows for ASCII characters
- If there is an exception, the Message Routing Headers are not included in the response.
- Parsing errors in the JSON request body are not reported to the requester
- Not Base64-encoded authorization token results in HTTP 500 error
- Ignore unknown properties.
- Skip NULL values in Connector.tariff_ids HOT 1
- Partner URL is not a unique identifier HOT 4
- date_from in Sessions Sender Interface must be required HOT 1
- twentyforseven should be "twentyforseven" not "twenty_for_seven" HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ocpi-toolkit.