+1
Jacques
Le 26/09/2020 à 13:56, Deepak Dixit a écrit :
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
