Normally, from developer machine, if we want to use, Sitecore CLI for serialization, we would have used the commands,
dotnet sitecore login –auth “IdentityServerURL” –cm “CMS URL” –allow-write true
which would open the browser and redirect you to Identity Server Login page for Authentication, Once you enter the User Name/Password your session will be authenticated and you would be able to perform the serialization.
If you were to setup a pipeline that does this serialization, using the same approach is not quite possible. Because, everything needs to be automated to the maximum. In order to tackle such cases, Sitecore provides a Non-Interactive way to login->get authenticated and use that authentication/authorization for further serialization process. The command for sitecore non interactive login is,
dotnet sitecore login –authority “IdentityServerURL” –cm “CMS URL” –allow-write true –client-credentials true –client-id “Client ID” –client-secret “Client Secret”
It uses two new attributes – Client ID/Client Secret.
The Official Sitecore documentation, provides all the setup details. It is clear and almost has all the required details. But however, in spite following this article, I came across a couple of issues. Thought I will share about those issues and how we can overcome them here, hoping it helps the community.
Client ID/Client Secret:
- According to the sitecore documentation, in Sitecore.IdentityServer.DevEx.xml, we should be specifying the client secret/Client ID.
- This Client Secret/Client ID is based on ‘IdentityServer4.Configuration.IdentityServerOptions.InputLengthRestrictions‘ property, which doesn’t have any minimum length restrictions but the maximum length for these attributes is set to 100.
- So, if your client secret or client id is string of length more than 100 you might get the below error.
App Pool Recycle – Not Just restarting the web app
- According to the sitecore documentation, after the changes are done in both these config files, we have to restart these two applications.(CM/Identity Server Web Apps)
- But merely, restarting the app didn’t workout for me. I was still facing the “Error while getting client credentials token: invalid_client”
- I tried to replicate this issue in a plain vanilla instance and fortunately I was able to replicate this issue in plain vanilla as well. Reached out to Sitecore and mentioned about this issue to them. They recommended to recycle the app pool as well.
- So, after making the necessary config changes, it is recommended to recycle the app pool for these two instances as well. Esp. identity server role.
- After recycling the app pool, after making a config change, this issue is resolved.
This kinda made me, go through the basics once again. What does restart a web app in IIS do and what an app pool recycle do. Sharing that info below.
App Pool Recycle:
“When you recycle an application pool, IIS will create a new process (keeping the old one) to serve requests. Then it tries to move all requests on the new process. After a timeout the old process will be killed automatically. You usually recycle your application pool to get rid of leaked memory “
I guess this makes sense as to why the issue I faced with the login was fixed after app pool recycle.
App Restart:
"As for restarting a website, it just stops and restarts serving requests for that particular website."
Also, makes sense.
Sitecore Blog 