Thanks Gavin,
I'd just note that in this case your are not protected from CSRF. Fortunately the REST effort is only in trunk. And, as explained in
security.properties, in trunk we can use org.apache.ofbiz.security.CsrfDefenseStrategy in such case.
Jacques
Le 26/09/2020 à 07:38, Gavin Mabie a écrit :
Sessions are extremely useful and even indispensable for an ERP system
where statefullnes are critical for audit trail purposes. Stateless
requests don't care about transactions beyond the actual request/response.
Besides, sessions are only problematic when a new session gets created for
each REST API request. You can prevent this by setting the cookie SameSite
property to "None". That way sessions and REST request can happily live
together.
On Sat, Sep 26, 2020 at 6:35 AM Girish Vasmatkar <
[email protected]> wrote:
Hi
I am using userLogin service to authenticate users before generating auth
tokens for REST API and GraphQL calls. However, I 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, I still think
it is an extra session lying around in tomcat's session cache.
I propose 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.
Anything else you think should be part of the new service instead of just
username/password validation?
Best,
Girish
HotWax Systems
