[jira] [Commented] (OFBIZ-12033) Separate login service for API calls

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[jira] [Commented] (OFBIZ-12033) Separate login service for API calls

Nicolas Malin (Jira)

    [ https://issues.apache.org/jira/browse/OFBIZ-12033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17304744#comment-17304744 ]

Girish Vasmatkar commented on OFBIZ-12033:
------------------------------------------

[~mbrohl]

This has been implemented in such a way that each app or plug-in can provide their own set of APIs. What you described about is still achievable and working in current implementation. The root or context path for the root will start from /rest/ and then each different plugin or app will provide their own APIs/paths.

In your example above, all REST API # can be included in separate plug ins and each one providing their own root path viz. /webshop/, /pim/, /cdn/ .

As far as having separate swagger pages goes, it is not yet supported but it was in my to-do list to have separate swagger page for separate APIs exposed by separate plug ins.

On the versioning, the version number can also be included in the path itself or I am thinking that there can be a dedicated XML element named "version" which will assign version number to all endpoints that fall under the version number.

Best,

Girish

> Separate login service for API calls
> ------------------------------------
>
>                 Key: OFBIZ-12033
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-12033
>             Project: OFBiz
>          Issue Type: Sub-task
>          Components: ALL COMPONENTS
>            Reporter: Girish Vasmatkar
>            Assignee: Girish Vasmatkar
>            Priority: Minor
>
> We're using {color:#2a00ff}userLogin {color}{color:#000000}service to authenticate users before generating auth tokens for REST API and GraphQL calls. However, we figured that a session is also getting created and returned in response which is defeating the purpose of having an API in place. Even though that session is not getting used anywhere when subsequent calls are made using the token, we still think it is an extra session lying around in tomcat's session cache. {color}
> {color:#000000} {color}
> {color:#000000}Proposal is to implement a new basic userLogin service (basicAuthUserLogin) that would just do username/password matching and be done with it without ever calling request.getSession(). This will ensure that APIs are stateless and no session is generated.{color}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)