Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Store OCPI platforms party_id and country_id #27

Closed
atschabu opened this issue Dec 1, 2023 · 2 comments · Fixed by #32
Closed

Store OCPI platforms party_id and country_id #27

atschabu opened this issue Dec 1, 2023 · 2 comments · Fixed by #32
Labels

Comments

@atschabu
Copy link
Contributor

atschabu commented Dec 1, 2023

Currently the library only stores a platforms tokens, combined with the versions URL as identifier. While this is sufficient for authentication of a remote party, it isn't enough to identify them. We currently workaround this issue by storing the platforms country_code and party_id when storing TOKEN_A, though this could be handled by the library as part of the registration process, by downloading the other platforms Credentials once tokens have been exchanged.

The reason we need this information, is to identify calls made to Session endpoints, so we can filter return values based on the caller (eg: only return Sessions, that were initiated by Tokens owned by the calling eMSP). Similarly, when pushing Session objects to an eMSP, at the time of creating the Session object, all we have are the identifiers of that platform, and not its base URL.

The simplest solution would be, to keep the platformURL as identifier and add methods to the PlatformRepository interface for associating the identifiers:

    suspend fun getPlatformUrlByIdentifiers(country_code: String, party_id: String): String?
    suspend fun savePlatformIdentifiers(platformUrl: String, List<IdentifierPair>: String)
@atschabu
Copy link
Contributor Author

atschabu commented Dec 1, 2023

oh .. and maybe also a retrieval method for the identifiers, similar to the getEndpoints method

    suspend fun getPlatformIdentifiers(platformUrl: String): List<IdentifierPair>

... though at this point I wonder if it would be easier to have a Platform domain object, containing all this info (url, versions, endpoints, identifiers) so it is expandable, and simplifies the interface by removing a few getters

@lilgallon
Copy link
Member

I agree with you. In this PR: #23, I updated and fixed a few things in credentials module. To keep all the information exchanged by a partner, we will store its list of CredentialsRole (it includes countryCode / partyId).

Then in your implementation, you can extend PlatformRepository to add your custom methods to retrieve a Platform object from its countryCode / partyId or anything else.

As long as the ocpi-toolkit does not directly need countryCode / partyId to work, we do not need to add methods to retrieve this information in PlatformRepository. It's up to the user of the lib to implement its own method to return the right information in each OCPI endpoint.

I may miss something as I am currently only testing credentials and version module with real partners. I started working on Location module recently, that is why I found out that the lib needed to store countryCode / partyId.

I am not totally convinced about having a Platform domain object yet. Real world feedback may convice me, but for now I prefer that the user of the lib keeps freedom on their Platform definition

PS: I will rename Platform to Partner as platform is not really clear in PR #23

@lilgallon lilgallon added the enhancement New feature or request label Dec 1, 2023
@lilgallon lilgallon mentioned this issue Dec 1, 2023
16 tasks
@lilgallon lilgallon mentioned this issue Dec 1, 2023
16 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants