SharePoint By Gaurav Goyal

Hi, I have created a provider hosted app for SharePoint. It got expired due to validity of secrete because usually client secret validity is one year. Now the app started throwing exception to me i.e. ""Invalid JWT token. Could not resolve issuer token." I did couple of research on it & found the solution from site "https://docs.microsoft.com/en-us/sharepoint/dev/sp-add-ins/replace-an-expiring-client-secret-in-a-sharepoint-add-in". I have made some changes in this script to make little bit easier to use . Here is the script : #Actual Article #https://docs.microsoft.com/en-us/sharepoint/dev/sp-add-ins/replace-an-expiring-client-secret-in-a-sharepoint-add-in #MSOnline #Get help from : https://www.powershellgallery.com/packages/MSOnline/1.1.166.0 #Inspect #PS> Save-Module -Name MSOnline -Path <path> #Install #PS> Install-Module -Name MSOnline cls #Get app details Connect-MsolService $clientID = “<<YourClientIdGuidHere>>” Write-Host ...

Introduction One of the new features being added to version 4.0 of ASP.NET is the ability to control the client side IDs that are generated by the framework.  Previously the framework would modify the client side IDs to uniquely identify each control.  This some times left you with the ID you defined in markup or sometimes left you with something that looks like this, “ctl00_MasterPageBody_ctl01_Textbox1.” The Problem The modification of the client side id property works great to ensure that each element is uniquely identified, however, to anyone that has tried to do any sort of client side scripting this becomes very frustrating. Chances are that if you have worked in ASP.NET for any time at all you have run into this issue.  The problem is that until runtime you do not what the client side ID could be, making it difficult to do any kind of client side scripting.  In addition any modification of the page, adding removing controls, can result in a d...