Open tomhula opened 2 days ago
Could this be fixed with: https://github.com/Kotlin/kotlinx-rpc/issues/150 ?
I am not a contributor, this is just my opnion
It depends on the posibilities of the plugins. But yes, if the plugins would be able to modify the actual request, then it should be possible to make an Authentication plugin. And actually I think making it an extension plugin is a great idea, similiar to Ktor's.
Hi, @tomhula! Thank you for the feature request. We are thinking about protocol enhancements, and we'll take this into consideration during the design. Either it would be done by plugins, or by a separate feature - I don't know yet
Is your feature request related to a problem? Please describe. Somewhat yes. Consider the following REST resource: GET, POST: /articles In this case, you need to be authenticated to post an article. However to get all the articles, you can and don't have to be authenticated. If you are not, you will receive only the public articles. If you authenticate, you will also receive those, that you have permission to view.
Using Kotlinx RPC, I would imagine that you would create an ArticleService, that would have the getAll and post methods. However how do you handle the authentication? What I have understood is that when you use the Ktor server implementation, you can protect the entire route, however, that has many downsides:
Describe the solution you'd like I am not entirely sure how this library is implemented, so keep that in mind please. Add a feature, similiar to http headers. Each call, would apart from what service is being called and what are the arguments also be able to carry additional data, that could contain the authentication information. This would also be a helpful addition overall, that you could pass additional context/state data. I am not entirely sure, whether the authentication should be part of this additional data feature, or it should be handled seperately. Handling it seperately might have an adventage, where some transport implementation can have specific custom ways of handling authentication.
Describe alternatives you've considered I have already described above.
Additional context I have read all the issues related to authentication, however to my understanding the provided solutions do not solve above problems.