I'm trying to Authorize Dev Hub in SF, It opens up a browser window to login and once I put my Credentials and click login, The Page Simply Keeps Loading, Never Finishes loading.
I have everything in place, SFDX is installed, VS Code Extensions for SF installed, The Dev Hub is enabled from the App settings.
Saw Various Videos and Articles on this but no solution works in my case. Tried all options available in VS Code Command Palette related to Authorization and also tried doing it using cmd.
Please Help.
Thanks in Advance
Any Other Information can be provided on demanded.
You need to make sure that your user profile has access to the connected apps like Salesforce CLI.
I had the same issue. So, I created a permission set and added this set to my user. That solved the problem.
Try to install this plugin with the following command: "sfdx plugins:install salesforcedx#48.22.11"
Im developing TFS extension using angular and when I debugging the extension I unable to make rest calls using the VSS SDK, it try to make a request to WebPlatformAuth but it throw exception:
"Error issuing session token: HostAuthorizationNotFound".
Just to make it clear, Im able to use VSS to get WebContext for example project.name or user.id.
(I debug my extension by running ng serve on my localhost and provide the extension manifest "baseUri" field).
UPDATE - It happen also when I deploy the extension without the baseUri - not in debug mode.
Just to mention, I also developed another simple extension using only html and jquery and it worked just fine without any additional configurations.
Apparently I just had to enter the 'manage extensions' page at the Azure Devops and give my extension the authorization to the actions it ask for.
Uninstalling and reinstalling seemed not to help because we switched to a different version of the extension. When I uninstalled and reinstalled the SAME version, the extension worked again!
We're in the process of moving from on-premise build servers to Azure Pipelines. We produce "shrink-wrap" desktop software so clearly we need to sign all our binaries before releasing. Our current build infrastructure does this using a USB hardware token from GlobalSign, but clearly that isn't going to work when we're doing cloud builds - sadly, clouds are not equipped with USB ports :D
Now, GlobalSign has recently started advertising Azure Key Vault as a key storage option, and they're perfectly happy to sell this to us, but I'm not sure how we'd actually integrate that with our build pipelines (or indeed whether that's even possible).
Has anyone actually made this work?
Code Signing
I've been battling with Azure Key Vault and Azure Pipelines to get our code signed, and succeeded. So here's what I found out.
Critically, Extended Validation (EV) certificates used for code signing are very different animals to 'normal' SSL certificates. The standard ones can be exported as much as you like, which means you can upload it to Azure Pipelines and use it with the standard Microsoft Sign Tool.
However, once an EV certificate is in Azure Key Vault, it isn't coming out in any usual fashion. You must call it from Pipelines using the excellent Azure Sign Tool as discovered by Anodyne above
Get your certificate into Key Vault. You can use any certificate authority you like to generate the certificate, as long as they understand that you'll need an EV certificate, and critically one that has a hardware security module (HSM), and not one with a physical USB key. Any cloud based system like Key Vault will need an HSM version.
To get the permissions to access this certificate externally you can follow this page but beware it misses a step. So read that document first, then these summarised steps, to get the Key Vault set up:
Open the Azure portal, go to the Azure Active Directory area, and create an App registration: put in a memorable name, ignore the Redirect URI, and save it.
Go to your specific Key Vault, then Access control (IAM), then Add role assignment. Type the name of the app you just created into the select input box. Also choose a Role, I suggest Reader and then save.
The Missing Part: Still in the Key Vault, click the Access policies menu item. Click Add Access Policy and add your application. The Certificate Permissions need to have the Get ticked. And the Key Permissions, despite the fact that you may not have any keys at all in this vault, need to have Get and Sign. You would have thought these two would be in the certificate perms...
Go back to the application you just created. Select the Certificates & secrets, and either choose to upload a certificate (a new one purely for accessing the Key Vault remotely) or create a client secret. If the latter, keep a copy of the password, you won't see it again!
In the Overview section of the app will be the Application (client) ID. This, and the password or certificate, is what will be fed to the Azure Sign Tool later on in a Pipelines task.
Handling the actual code signing from Azure requires a number of steps. The following applies to Microsoft hosted agents, although similar issues will affect any private agents that you have.
The Azure Sign Tool needs the .NET Core SDK to be installed, but a version that's at least version 2.x, and since the latest .NET Core SDK is always used, this means as long as the version of Windows is current enough, you don't need to install it yourself. And you can see which version of the SDK is shipped with which Windows agent.
The current Hosted OS version in Azure Pipelines, also called Default Hosted, is, at the time of writing, Windows Server 2012 R2. Which isn't up to date enough. Installing a newer .NET Core SDK to overcome this is a time drag on every build, and although the installation works, calling the Azure Sign Tool may not work. It seems to be finding only older versions of the SDK, and throws this error: Unable to find an entry point named 'SignerSignEx3' in DLL 'mssign32'.
So the easiest thing to do is change your build to use a later OS image. Windows 2019 works like a charm. And there is no need to install any version of .NET Core.
Then create a command line task to install the Azure Sign Tool. You can use a .NET Core CLI task as well, but there is no need. In the task, type this:
set DOTNET_SKIP_FIRST_TIME_EXPERIENCE=true
dotnet tool install --global AzureSignTool --version 2.0.17
Naturally using whichever version that you want.
The DOTNET_SKIP_FIRST_TIME_EXPERIENCE environment variable isn't strictly necessary, but setting it speeds things up quite a bit (see here for an explanation).
Finally, create another command line task and type in the Azure Sign Tool command that you wish to run with. On Windows this would be something like below, note with ^ not / as a line continuation marker. Naturally, see here for more parameter information:
AzureSignTool.exe sign -du "MY-URL" ^
-kvu https://MY-VAULT-NAME.vault.azure.net ^
-kvi CLIENT-ID-BIG-GUID ^
-kvs CLIENT-PASSWORD ^
-kvc MY-CERTIFICATE-NAME ^
-tr http://timestamp.digicert.com ^
-v ^
$(System.DefaultWorkingDirectory)/Path/To/My/Setup/Exe
And in theory, you should have success! The output of the sign tool is rather good, and usually nails where the problem is.
Re-issuing Certificates
If you need to re-issue a certificate, the situation is quite different.
In Azure, go to the certificate and click on it, opening a page showing the versions of that certificate, both current and older versions.
Click the 'New Version' button, probably accepting the defaults (depending on the choices you wish to make) and click 'Create'.
This takes you back to the Versions page, and there will be a message box stating 'The creation of certificate XXXX is currently pending'. Click there (or on the 'Certificate Operation' button) to open the 'Certificate Operation' side page. Once there, download the CSR (certificate signing request).
In GlobalSign, follow their instructions to re-issue the existing certificate. Once it has been re-issued, they will send an email describing how to download it.
Log into GlobalSign again, and after entering the temporary password, open the CSR and copy the whole text (which starts with -----BEGIN CERTIFICATE REQUEST-----) into GlobalSign. Submit it.
Download using the 'Install My Certificate' button. Then in the Azure 'Certificate Operation' side page - use the 'Merge Signed Request' button that to upload the .CER file to Azure. This creates the new version of the certificate.
Disable the old version of the certificate.
Yes, it's able to do this in Azure DevOps Service Build pipeline.
For normal situation, we usually use SignTool.exe commands to sign files. There is also an extension Code Signing in marketplace, which could sign a single file, you could use script to run SignTool.exe commands for multiple files.
So you can export your codesigning certificate to a pfx file, which you then upload as a secure file to Azure Devops secure file storage which makes it available to your builds.
Azure DevOps could store secure files. Check this link for details: Secure files
Azure Key Vault instance is kind of more complicated. We also have an Azure Key Vault task.
Use this task in a build or release pipeline to download secrets such
as authentication keys, storage account keys, data encryption keys,
.PFX files, and passwords from an Azure Key Vault instance.
The task can be used to fetch the latest values of all or a subset of
secrets from the vault, and set them as variables that can be used in
subsequent tasks of a pipeline.
Not sure how GlobalSign will integrate code sign with your environment. Theoretically, it's able to do this. For the detail parts and implementation, you may need to discuss with their pre-sales. Hope this helps.
If anyone else is looking for this and using RBAC, I found these steps essential:
Key Vault Reader on the RESOURCE GROUP
Key Vault Certificates Officer on the KEY VAULT and on the CERTIFICATE
Key Vault Crypto Office on the CERTIFICATE (to use the key for signing!)
I was trying to use source control for my mobile services. But it prompts me to enter a username and password for deployment. I don't actually remember if I had ever set one before. And I couldn't find a way to reset this. It appears to be a simple task for web apps but I can't figure out how to do this in AMS. Thanks in advance for your help.
OK. Apparently this is the same deployment credential used for other Azure services like Web apps as well. So I was able to reset it on webapps. But this is rather annoying because the Azure Mobile Services documentation points to an option that doesn't exists in this article if you had previously use deployments on other services. https://azure.microsoft.com/en-us/documentation/articles/mobile-services-store-scripts-source-control/
For various reasons we have decided to try to sidestep the slug-compilation and build our own slug locally to deploy through the API (as described here: https://devcenter.heroku.com/articles/platform-api-deploying-slugs).
The slug is built mostly like the java/scala buildpack using that buildpack jvm and is then combined with our play framework application dist file. Looking at the app dir of a normal/git-deployed app it looks aboutish the same.
Now, after deploying the slug through the api we get the expected dynos listed in the config page but the app crashes right away without giving any further information. Trying to attach a bash shell through heroku run bash it just times out.
Is there any way to get more information about why the app crashed out of heroku?
Ok, after some help from heroku support we figured out the following:
The slug tar files must be created so that the paths start with './' regular relative paths doesn't cut it. When we had that figured out we didn't really have any more big problems and now we have got a working alternative build and deploy to heroku pipeline that allows us to build or app locally and then deploy that.