+1 Thanks. Mridul Pathak
On Tue, Sep 29, 2020 at 1:29 PM Michael Brohl <[email protected]> wrote: > +1 > > With an addition: we should do the implementation in a way that the > user/password matching is implemented only once and used in both login > methods (not just copy & paste into another method). > > It might take some refactoring to pull these part out of the login event. > > Best regards, > > Michael Brohl > > ecomify GmbH - www.ecomify.de > > > Am 29.09.20 um 09:43 schrieb Jacopo Cappellato: > > +1 > > > > Jacopo > > > > 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 > >> > >
