OAuth already has a standard login protocol which creates a token. My issue is with using HTTP session cookies as they go away in a few mins of idle time (max). The command line client is calling proper OAuth APIs right? In that case it should just use the OAuth token right? It certainly should not be storing user/pass under any condition.
For the app, if the objective is to maintain a browser login then the proper thing is to mimic what OAuth does. See: http://stackoverflow.com/questions/244882/what-is-the-best-way-to-implement-remember-me-for-a-website(the first answer). If the app is turning around and calling an API underneath the the DB table can store the OAuth token too so it can use that to make calls on behalf of the user. Why is basic auth involved at all here? Sanjiva. On Sun, Feb 2, 2014 at 8:38 PM, Pradeep Fernando <[email protected]>wrote: > Hi, > > If we introduce implicit cookie based authentication, then there need not > be seperate endpoint to retrieve the cookie. Then server should first try > to authenticate using session and if not try to authenticate using basic > auth headers if present. In this approach the application writer has to > decide on the first endpoint call (since he has to send in > username/password during the first invocation) > > Here what we are doing is, defining a explicit endpoint to do the same. > Even in the oauth, this is the flow i guess. we sent in > client-id/client-secret and get a arbitrary string and use that for > subsequent calls.. > > thanks, > --Pradeep > > > On Sun, Feb 2, 2014 at 8:07 PM, Pradeep Fernando <[email protected]>wrote: > >> Hi, >> Let me explain the original problem, so that you can suggest a better >> approach. >> >> - we are using basic auth headers to authenticate/authorize our rest >> backend. It works fine >> - We did not maintain sessions up until now. (not request.getSession >> method call) >> - We have two clients at the moment. A jaggery app and a command line >> client. >> - command-line client stores the username/password during the >> initialization and add basic auth headers to subsequent calls. >> - for webapp we introduced web-sso and oauth based solution. its working >> but there are certain setup steps. not the first experience we want to have. >> - Hence introduced this authentication endpoint that returns a cookie >> - I followed the approach similar to AuthenticationAdminEndpoint used in >> carbon servers. It returns a cookie and we use that to make subsequent WS >> calls... >> >> wdyt ? >> >> Thanks, >> --Pradeep >> >> >> >> On Sun, Feb 2, 2014 at 7:21 PM, Sanjiva Weerawarana <[email protected]>wrote: >> >>> Hmmmm this doesn't sound like a good idea to me. So you've introduced an >>> endpoint that the client calls to get the Java session ID associated with a >>> servlet session? >>> >>> Those session IDs are very transient .. they time out. That's not the >>> cookie used for remember me in GMail for example. >>> >>> In any case, you can get this ID from any response .. why do I need to >>> call a specific URL to get it? This is how clients maintain session - by >>> returning all the cookies the server sends. >>> >>> What am I missing to understand why this makes sense? >>> >>> Sanjiva. >>> >>> >>> On Sun, Feb 2, 2014 at 5:16 PM, Pradeep Fernando <[email protected]>wrote: >>> >>>> Hi, >>>> >>>> I Completed the $subject. Now you can get a jsessionId from the /cookie >>>> endpoint and use that in subsequent requests. >>>> >>>> I have used that in the web console as well. its working fine should be >>>> able to complete it by tomorrow. This is in addition to SAML SSO >>>> authentication. >>>> >>>> IMO, we should use the same mechanism in CLI as well. At the moment CLI >>>> is storing the username/password. It is not a good practice and CLI >>>> continue to work even when we restart the backend.. :) >>>> >>>> Sajith please look in to that if you have some time. >>>> >>>> flow listed below. >>>> >>>> endpoint url, >>>> >>>> /stratos/admin/cookie >>>> >>>> GET request. >>>> >>>> authenticate with basic auth. >>>> >>>> you get the JSESSIONID >>>> >>>> use that JSESSIONID as a cookie for subsequent requests. >>>> >>>> >>>> thanks, >>>> --Pradeep >>>> >>>> >>>> >>>> -- >>>> Pradeep Fernando. >>>> http://pradeepfernando.blogspot.com/ >>>> >>> >>> >>> >>> -- >>> Sanjiva Weerawarana, Ph.D. >>> Founder, Chairman & CEO; WSO2, Inc.; http://wso2.com/ >>> email: [email protected]; office: (+1 650 745 4499 | +94 11 214 5345) >>> x5700; cell: +94 77 787 6880 | +1 650 265 8311 >>> blog: http://sanjiva.weerawarana.org/ >>> Lean . Enterprise . Middleware >>> >> >> >> >> -- >> Pradeep Fernando. >> http://pradeepfernando.blogspot.com/ >> > > > > -- > Pradeep Fernando. > http://pradeepfernando.blogspot.com/ > -- Sanjiva Weerawarana, Ph.D. Founder, Chairman & CEO; WSO2, Inc.; http://wso2.com/ email: [email protected]; office: (+1 650 745 4499 | +94 11 214 5345) x5700; cell: +94 77 787 6880 | +1 650 265 8311 blog: http://sanjiva.weerawarana.org/ Lean . Enterprise . Middleware
