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

Michael Brohl commented on OFBIZ-12033:
---------------------------------------

Thanks [~rohit.koushal] for your observations and the patch!
{quote}While reviewing the implementation of the REST component, I discovered 
that it primarily focuses on exposing OFBiz services for REST calls. But what 
if a service takes a complex object, such as a user-defined class (e.g. 
GenericValue)? In that case, it may be necessary to define data mappers or do 
we have a better solution?
{quote}
Yes, we'll need a mapping mechanism to/from complex objects. We have a 
configurable solution for this worked out for OFBIZ-12517 using annotated java 
objects.

We have a field tested overall solution for the subtasks of OFBIZ-11328 which 
is going to be contributed.
{quote}Additionally, I discovered three methods for creating APIs with the 
existing code, but I couldn't find any documentation or examples for two of 
them. Do we have documents that I am missing?
{quote}
The documentation will be updated/enhanced with the above mentioned 
contributions as well.

What do you mean by the first solution
{quote}Using a Java Resource
{quote}

> 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
>         Attachments: OFBIZ-12033.patch
>
>
> 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.10#820010)

Reply via email to