You're right Jacques. SameState=None exposes CSRF. Thanks for pointing that out.
On Sat, Sep 26, 2020 at 10:34 AM Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: > 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 < > > girish.vasmat...@hotwaxsystems.com> 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 > >> >
