[
https://issues.apache.org/jira/browse/OFBIZ-12033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17463297#comment-17463297
]
Michael Brohl edited comment on OFBIZ-12033 at 12/21/21, 3:03 PM:
------------------------------------------------------------------
[~gvasmatkar] ,
I analyzed the userLogin service method and cannot find evidence for the
following statement in this issue's description:
{quote}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}
{quote}
{color:#000000}I do not see any code which creates a session. Maybe you
confused this with the creation and return of the UserLoginSession
entity?{color}
{color:#000000}There is some code dealing with a HttpRequest object if Tomcat
SSO is switched on AND the request object is provided as a service parameter.
This was introduced by OFBIZ-10047 and should be changed, see reopened issue
there.{color}
{color:#000000}The login service provides functionality which is also useful
for the REST login, like for example login history or external
authentication.{color}
{color:#000000}So all in all, I currently do not see the need for another
userLogin service, or do I oversee something?{color}
EDIT: we still have the need for endpoint security and permission handling but
I first wanted to be sure that I do not miss something regarding the userLogin
service.
was (Author: mbrohl):
[~gvasmatkar] ,
I analyzed the userLogin service method and cannot find evidence for the
following statement in this issue's description:
{quote}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}
{quote}
{color:#000000}I do not see any code which creates a session. Maybe you
confused this with the creation and return of the UserLoginSession
entity?{color}
{color:#000000}There is some code dealing with a HttpRequest object if Tomcat
SSO is switched on AND the request object is provided as a service parameter.
This was introduced by OFBIZ-10047 and should be changed, see reopened issue
there.{color}
{color:#000000}The login service provides functionality which is also useful
for the REST login, like for example login history or external
authentication.{color}
{color:#000000}So all in all, I currently do not see the need for another
userLogin service, or do I oversee something?{color}
> 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: Michael Brohl
> 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.20.1#820001)
