Hi Girish, I think it's a good idea to use a separate login method for REST to avoid sessions.
We have *userLogin* service that do the login related work, so we can have separate wrapper method for REST like LoginWorker.login() Kind Regards, Deepak Dixit On Sat, Sep 26, 2020 at 2:54 PM Girish Vasmatkar < girish.vasmat...@hotwaxsystems.com> wrote: > Hello > I am not sure if we can talk about sessions when we're talking about REST. > The REST implementation is mapping Resources with OFBiz services and the > services are executing in a context using "userLogin" and that is all the > REST implementation is doing. Extracting userLogin from token and supplying > to the OFBiz service. > > The session you get from running userLogin service is not getting used for > subsequent API calls made using JWT token because usual OFBiz flow > (ContextFilter, ControlServlet) don't come in picture. Therefore, I feel, > as far as REST implementation is concerned, it is better to create a > separate service that does just authentication and doesn't create sessions. > > Also, a properly designed REST endpoint without cookies means no CSRF. > > Best, > Girish > HotWax System > > > > > > > > > On Sat, Sep 26, 2020 at 2:04 PM 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 > > >> > > >
