Hi Sameera, On Fri, Jul 19, 2013 at 12:15 PM, Sameera Jayasoma <[email protected]> wrote:
> Supun access token is a encoded string which contains the information of > the end user, application, scope and other attributes. If the same user > requests a token via different app, he will get a different app. > Sorry, I didn't mean the store app. Just think a "webapp" log-in is integrated to /token call. So if someone with same credentials logs in again expiry time will get changed.. > I am not suggesting to keep timers. Rather when ever you do a call, check > whether your token is expired. We have successfully implemented this > approach in another project. Its much more efficient than getting the error > code first and then invoking the /token endpoint. It involves two remote > calls. But if you keep track of the token expiry time, you can reduce it to > 1 remote calls. > I do understand what you mean and the easeness, but in my use case user is already logged into the webapp (which I mentioned earlier) and he uses the access token to do api calls within the webapp. So unless having a timer or similar mechanism how is it possible to get the token refreshed before the token expires?. But still previous issue is a concern.. thanks, > > On Fri, Jul 19, 2013 at 12:06 PM, Supun Malinga <[email protected]> wrote: > >> Hi Sanjeewa, >> >> Looks like this error code is generic?. Could you pls point me where it's >> initiating?. In my user case it starts with user invoking /token and >> getting a valid user token. So token revoke won't be applicable? (unless >> someone intentionally did). >> >> @Sameera, >> I believe keeping track of the expiry time wouldn't be the correct >> approach here. One reason is that expiry time will change(reduce) if same >> user requests /token again (via diff app., etc). Also it would be a >> overhead to keep a timer until the token expires.. >> >> >> >> >> On Wed, Jul 17, 2013 at 6:33 PM, Sameera Jayasoma <[email protected]>wrote: >> >>> Or else you can use the expiry time of an access token as a mesure. When >>> you request the access token first time, you get the access token, refresh >>> token as well as the expire time. Whenever you need to invoke the API >>> again, check the expiry time with the current time. >>> >>> If the token is expired then use the refresh token to get a new token. >>> This method should be efficient IMO. Otherwise you will have to do a call >>> to get to know whether the access token is expired or not. >>> >>> Thanks, >>> Sameera. >>> >>> >>> On Wed, Jul 17, 2013 at 5:12 PM, Sanjeewa Malalgoda >>> <[email protected]>wrote: >>> >>>> Hi supun, >>>> >>>> On Wed, Jul 17, 2013 at 4:18 PM, Supun Malinga <[email protected]> wrote: >>>> >>>>> Hi, >>>>> >>>>> I can see the response for API invocation with an expired token is, >>>>> <ams:fault >>>>> xmlns:ams="http://wso2.org/apimanager/security";><ams:code>900904</ams:code><ams:message>Access >>>>> Token Inactive</ams:message><ams:description>Access failure for API: >>>>> /test, >>>>> version: 1.0.0 with key: >>>>> 2974848455beee48d9012df0bb9a72</ams:description></ams:fault> >>>>> >>>>> So can I user the given error code (900904) specifically detect a >>>>> token expiry scenario?. >>>>> >>>> We used this code to indicate that access token is inactive state(It >>>> can be revoked or expired). You can use generally this code to detect token >>>> is in invalid state. >>>> >>>> Thanks, >>>> Sanjeewa. >>>> >>>>> >>>>> If not what is the correct way to do this?. >>>>> >>>>> thanks, >>>>> -- >>>>> Supun Malinga, >>>>> >>>>> Senior Software Engineer, >>>>> WSO2 Inc. >>>>> http://wso2.com >>>>> http://wso2.org >>>>> email - [email protected] <[email protected]> >>>>> mobile - 071 56 91 321 >>>>> >>>>> _______________________________________________ >>>>> Dev mailing list >>>>> [email protected] >>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>> >>>>> >>>> >>>> >>>> -- >>>> * >>>> * >>>> *Sanjeewa Malalgoda* >>>> WSO2 Inc. >>>> Mobile : +94713068779 >>>> >>>> <http://sanjeewamalalgoda.blogspot.com/>blog >>>> :http://sanjeewamalalgoda.blogspot.com/<http://sanjeewamalalgoda.blogspot.com/> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Dev mailing list >>>> [email protected] >>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>> >>>> >>> >>> >>> -- >>> Sameera Jayasoma, >>> Architect, >>> >>> WSO2, Inc. (http://wso2.com) >>> email: [email protected] >>> blog: http://sameera.adahas.org >>> twitter: https://twitter.com/sameerajayasoma >>> flickr: http://www.flickr.com/photos/sameera-jayasoma/collections >>> >>> Lean . Enterprise . Middleware >>> >> >> >> >> -- >> Supun Malinga, >> >> Senior Software Engineer, >> WSO2 Inc. >> http://wso2.com >> http://wso2.org >> email - [email protected] <[email protected]> >> mobile - 071 56 91 321 >> > > > > -- > Sameera Jayasoma, > Architect, > > WSO2, Inc. (http://wso2.com) > email: [email protected] > blog: http://sameera.adahas.org > twitter: https://twitter.com/sameerajayasoma > flickr: http://www.flickr.com/photos/sameera-jayasoma/collections > > Lean . Enterprise . Middleware > -- Supun Malinga, Senior Software Engineer, WSO2 Inc. http://wso2.com http://wso2.org email - [email protected] <[email protected]> mobile - 071 56 91 321
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
