SharePoint has emerged to be one of the most beneficial web application development platforms these days. The newer versions of this platform have turned out to be of immense use for the business enterprises as, they assist in the successful accomplishment of several tasks and necessitate much less time and efforts. Now, developers are trying out more innovative ways of exploiting SharePoint so as to derive the maximum advantages out of this already useful platform. Controlling the app token lifetimes in SP 2013 is one area of concern that is emphasized upon to a significant extent.
The first question that arises in this regard is where one can control the app token lifetimes. However, when considered on a broader platform, it will be seen that the place of control is actually not so significant and that a highly advanced app like TokenHelper can be of substantial help. There are around one or two JWT tokens that are created if one goes by the IssueToken method. It is usually one when the app only token is being used and two tokens for the application and the current user. However, in both the events, the JsonWebSecurityToken is created and the parameter that is used to create the same determines as to how long it is valid.
It is for the app token that the TokenHelper makes use of a constant, which is known as TokenLifeTimeMinutes. By default, this constant has a value of 1,000,000, which leaves no scope of worrying except in cases where one wants to limit it. Now, for the user token, the constant is hard- coded by default for making use of a lifetime of 10 minutes. The values can be found as well as changed into whatever you want just with a little drilling into the IssueToken method.
With a deeper look into the code, it can be seen that the TokenHelper incorporates a delegate that is invoked in what is known as the GetClientContextWithAccessToken method. This method plays the important role in adding a bearer token to any particular request that comes into the SharePoint from the particular app of the user.
Now, if the user sets a breakpoint on that specific line of code and eventually step through the request from the app, none of the token ‘setup’ functions creating the ClientContext will be resulting in an HTTP call. At this point, the ExecuteQuery method has to be called on the ClientContext object. The request goes over the wire, the delegate fires and finally, the token is added to the request. While one can cache the access token obtained in the high trust app, there may not always be a justified reason behind doing so.
On the other hand, caching the app tokens is beneficial only at the time of using the relatively low trust apps. When such is the case, one has to save one or more trips to ACS for the purpose of accessing token at the time of caching them. In events where there are multiple users or several requests, the process helps. The only thing that one needs to be aware of in this regard is the right ways of caching the tokens for the low trust apps.
This is just a brief overview of the overall process of controlling application lifetimes in SharePoint 2013 along with a discussion about the use and benefits of the high trust as well as the low trust apps. However, it is a task that needs to be taken up by only the experts and pros in the field, who are aware of the processes and can therefore, adept in handling the same to produce faster results in less time.
You can hire developers from top SharePoint development companies in India who can help you build products within allocated budgets and time schedules.