[
https://issues.apache.org/jira/browse/OFBIZ-12033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17304769#comment-17304769 ]
Michael Brohl commented on OFBIZ-12033:
---------------------------------------
Thanks, [~gvasmatkar] ! I'll try this out by implementing some test scenarios.
What about the initial question:
How do we assign the valid user login(s) to different REST endpoints? We certainly don't want to let *any* UserLogin be using the endpoints (see below).
There can be dfferent scenarios:
* the assignment is implicit because of some registration (also through the REST API, e.g. in an app)
* the assignment is configured in the backend (manually created UserLogins)
> 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)
Locked
