Keep the access token in user session. Before you do an API call, compare the expiry time with the current time. The logic is simple.
Sameera. On Fri, Jul 19, 2013 at 12:25 PM, Supun Malinga <[email protected]> wrote: > 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 > -- 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
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
