Open ewf-devops opened 3 years ago
Original comment by Adam Staveley (Bitbucket: [Adam Staveley](https://bitbucket.org/Adam Staveley), GitHub: adamstaveley).
Had a few ideas about the implementation. We could have either:
I much prefer the first option as the second option is not compatible with OCPI (would require responding to a request with another request).
Original comment by Adam Staveley (Bitbucket: [Adam Staveley](https://bitbucket.org/Adam Staveley), GitHub: adamstaveley).
As an aside, we might consider grouping permission IDs together (how status codes work). If we implement this we will have 0-40 IDs which aren’t very descriptive. A better approach could be to have:
and so on. This would also be compatible with the existing permissions smart contract which only requires that IDs are uint256
.
Original comment by John Henderson (Bitbucket: [John Henderson](https://bitbucket.org/John Henderson), GitHub: jrhender).
Interesting proposal, seems like a powerful feature!
@{5efc3c2c54020e0ba82c6e64} Good idea re the permission ID semantics. We could add 1000 to existing permissions to migrate or, at the very least, just have the newly defined permissions for interception start at 2xxx and leave the existing permissions as is.
Nice initial thinking on the implementation approaches :thumbsup:
For approach 1 (Service forwards message), I think that we would need to augment/modify the OCPI message format somehow, as when the OCN Node would forward the message to the service, the original destination party-id
and country-code
headers would be lost (as they would replaced with the service’s). We could, for instance, add HTTP headers like original-OCPI-to-country-code
. I think this information would also often useful to a service when receiving a forwarded request (in addition to requests they are intercepting).
Approach 2 seems like more effort from an OCN Node standpoint but one advantage may be that it provides a simpler, more intuitive mental model of the service acting as a filter or middleware (at least I find that intuitive).
Original comment by Adam Staveley (Bitbucket: [Adam Staveley](https://bitbucket.org/Adam Staveley), GitHub: adamstaveley).
@{5efed1cdf34eae0ba6f4d21c} yes, I was thinking something similar with the additional header. This wouldn’t affect normal usage of the OCN and would only require the service to accept it (which they should). The service would also change the from
OCPI headers, so we might also consider an original sender header as well, for the original recipient’s benefit. All this can be gleaned from the signature, but as I think we discussed in our last developer call, the API to retrieve such information from the Notary needs to be improved. Additionally, whilst signatures are still optional, we should provide the headers as well.
Original comment by Adam Staveley (Bitbucket: [Adam Staveley](https://bitbucket.org/Adam Staveley), GitHub: adamstaveley).
Btw, I wonder if we can automate the setting of these headers:
Original-OCPI-To
headers because they change the sender.Original-OCPI-From
headers, the OCN can automatically apply them (needs to figure it out from the signature). And maybe OCPI-origin-to/from
is better as it puts the application type first. We could also name it OCN-origin-to/from
instead, so that users know this is an OCN-specific header.
Original comment by John Henderson (Bitbucket: [John Henderson](https://bitbucket.org/John Henderson), GitHub: jrhender).
Notes from 2020-10 Developer Community call discussion:
Possible use cases:
Intercepting response could be complicated as some use cases (such as the dynamic pricing use case above) may require data from multiple parties
Another technique to “Approach 2” as suggested by Adam may be to use a callback URL
Though signatures (i.e. a “history” API provided by the OCN Notary) would be an elegant technique for “Approach 1”, signatures are not currently mandatory in the OCN. However, signatures are highly encouraged in production and we could perhaps require that they be enabled for certain features. Signature history would be nice because it would allow for multiple hops.
Additional example use cases would be helpful to determine all of the necessary requirements
Original report by Christopher Burgahn (Bitbucket: [Christopher Burgahn](https://bitbucket.org/Christopher Burgahn), ).
What is the motivation / use case for the feature?
The current implementation of the OCN Service Interface (Permissions and their OCN Node implementation) allows forwarding of OCPI requests. A useful addition to that could be “interception / changing of OCPI requests”. Some third-party services may need the option to intercept and change OCPI requests that are sent between two OCPI parties via the OCN. An example could be that a location is PUT by the CPO to the eMSP. A location enhancement service is then intercepting this request, changing the lat. & long. to optimize it for the eMSP, and will then forward it to the eMSP.
What are the requirements (or acceptance criteria) for the feature?
Any suggested implementation approaches?
Needs to be discussed