+1With 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 < 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
smime.p7s
Description: S/MIME Cryptographic Signature
