Maybe I'm misunderstanding how to create a cache but none of the the IDs or Access keys is working on the to enable the azure cache. I've gone through the following tutorials:
http://msdn.microsoft.com/en-us/library/windowsazure/gg618003.aspx
http://msdn.microsoft.com/en-us/wazplatformtrainingcourse_buildingappswithcacheservice_topic3#_Toc310505080
http://msdn.microsoft.com/en-us/library/windowsazure/gg618003.aspx
And about 1/2 a dozen different how to create a cache in azure pages and I'm still getting.
Authorization token passed by user Invalid.
I've got a website and cloud service with linked storage and nowhere can I find a url "yourcachename.cache.windows.net" or an Authentication Token in the manage Azure portal. Any suggestions would be greatly appreciated.
It turns out that I was getting confused between versions of Azure. I'm not sure what version this started in but I was working in 1.8 and I did not need an access key. Once I added the below sections to the web.config everything worked.
<dataCacheClients>
<dataCacheClient name="default">
<autoDiscover isEnabled="true" identifier="{your cache worker role}" />
<localCache isEnabled="true" sync="TimeoutBased" objectCount="100000" ttlValue="300" />
</dataCacheClient>
</dataCacheClients>
<cacheDiagnostics>
And then in order to get Sessions to work I needed to add this:
<sessionState mode="Custom" customProvider="AFCacheSessionStateProvider">
<providers>
<add name="AFCacheSessionStateProvider" type="Microsoft.Web.DistributedCache.DistributedCacheSessionStateStoreProvider, Microsoft.Web.DistributedCache" cacheName="default" dataCacheClientName="default" applicationName="AFCacheSessionState"/>
</providers>
</sessionState>
You need to login to the old portal via the link on the new portal, click on shared caching, service bus and access control. Create/Select a namespace and the auth token would be displayed on the right hand side bar.
Related
We have a simple Azure App Service app and part of that app accesses a SharePoint doc library to upload files. This has worked for years but recently stopped working. We generated a new clientid and secret thinking that was the problem - still no luck. We have been working with Microsoft for 3 weeks on the problem and they have been useless - they don't even know what a doc library is most the time and all they do is "take screenshots and will get back."
I can get a token and use it to pull resources in Postman just fine.
The following is the code in web.config:
`<appSettings>
<add key="webpages:Version" value="3.0.0.0" />
<add key="webpages:Enabled" value="false" />
<add key="ClientValidationEnabled" value="true" />
<add key="UnobtrusiveJavaScriptEnabled" value="true" />
<add key="ida:ClientId" value="spclientid" />
<add key="ida:AADInstance" value="https://login.microsoftonline.com/" />
<add key="ida:ClientSecret" value="spclientsecret" />
<add key="ida:Domain" value="ourdomain.com" />
<add key="ida:TenantId" value="tenantid" />
<add key="ida:PostLogoutRedirectUri"
value="https://login.microsoftonline.com/common/oauth2/v2.0/logoutsession/" />
</appSettings>`
Errors:1
Error :2
Error: 3
At our rope's end with this one, any ideas?
Thanks in advance.
• You must use ‘AllowAppOnlyPolicy=true’ in your manifest file for the registered Azure AD sharepoint app to acquire token from the registered application in Azure AD on behalf of the service principal created through your ‘App Service’. Also, you can grant the required permissions for accessing the sharepoint online website through your ‘App service’ as shown below in the snapshot through the Azure AD app registration portal instead of the ‘App manifest’ file: -
Thus, when you are providing the correct permissions to the ‘Sharepoint’ portal through this ‘Service Principal’ in Azure AD for OAuth 2.0 as well as configuring the ‘Authentication’ token and protocols too correctly, the Azure App Service should be able to access the Sharepoint doc library to upload files.
• Finally, please once again check the correct value of the secret ID and its value that is being used to connect to the sharepoint website on behalf of the SP app in Azure AD. Also, do check the correct tenant ID, domain and AADInstance of the registered SP for your app service, the details of which you have mentioned in the ‘App settings.json’ file of the code.
For more details and clarification on this, kindly refer to the below links explaining the issues regarding the ‘Sharepoint’ token helper issues and CSOM platform issues regarding various browsers that are used to try to access the same: -
https://github.com/SharePoint/sp-dev-docs/issues/6955
https://learn.microsoft.com/en-us/sharepoint/dev/spfx/use-aadhttpclient
Presumably there are lots of companies who are facing the same struggle we are.
For any microservice, before running a dotnet restore we need to first ensure we've successfully configured our ADO package feeds with an active token.
To achieve this we have a script which downloads and runs the CredentialProvider.VSS.exe (as suggested by Microsoft), using the output to build credentials which then register the feeds on the user's computer. This needs to happen daily as the tokens generated will expire.
The script above is ugly and worse yet, every repository needs it in order to ensure feeds are configured with active tokens. Even if we moved the ugly script to a PowerShell module for example, how would we authenticate against the PS feed in order to download that module?
I don't see why the CredentialProvider is neccessary, why can't nuget just prompt us for credentials whenever our token expires? Has anyone come up with a cleaner solution out there which manages authentication to ADO feeds across multiple repositories?
How to cleanly automate authentication for Azure Devops feeds?
To authentication for Azure Devops feeds, you could try to use the NuGet authenticate task, which configure NuGet tools to authenticate with Azure Artifacts and other NuGet repositories.
Then we could create a new NuGet service connection with PAT:
You can use a longer-term PAT for certification, so you don't have to change certification every day.
another approach using nuget.confg as below
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<add key="AzureDevOpsFeed" value="https://pkgs.dev.azure.com/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/index.json" />
<add key="nuget" value="https://xxxxxxxxxxxxxxxxxxxxx/index.json" />
</packageSources>
<packageSourceCredentials>
<VSTSFeed>
<add key="UserName" value="#{PAT_UserName}#" />
<add key="ClearTextPassword" value="#{PersonalAccessToken}#" />
</VSTSFeed>
</packageSourceCredentials>
</configuration>
Not sure if this is the right place to ask but... We have an older application that is set up to use SSO, currently Azure ADFS. I want to use login.microsoft.com url instead of our organizational url that has been used in the past.
I replaced the currently working links in web.config with the endpoints from Azure
<appSettings>
<add key="FederationMetadataLocation" value="https://login.microsoftonline.com/dfmi.onmicrosoft.com/FederationMetadata/2007-06/FederationMetadata.xml" />
</appSettings>
and
<federatedAuthentication>
<wsFederation passiveRedirectEnabled="true" issuer="https://login.microsoftonline.com/0845a734g7-6d23-7c96-9f4x-3427v39n4sd5/wsfed/" realm="https://customdfmi.dfmi.net/" requireHttps="true" />
<cookieHandler requireSsl="false" />
</federatedAuthentication>
I get to the sign-in page. When I put in the credentials it shows "AADSTS700016: Application with identifier 'https://customdfmi.dfmi.net/' was not found in the directory".
It is set up in Azure. Redirect URI is the exact copy of what's in web.config. What am I putting wrong in web.config? Do I need to put the Application ID somewhere in it? Any pointers would be great. Thanks!
Did you received this message?
AADSTS700016
UnauthorizedClient_DoesNotMatchRequest - The application wasn't found in the directory/tenant.
This can happen if the application has not been installed by the administrator of the tenant or consented to by any user in the tenant. You might have misconfigured the identifier value for the application or sent your authentication request to the wrong tenant.
I created a web application and added an ELMAH module for error logging. It was working with my local development environment: when i access URL http://localhost:52584/elmah.axd it shows me a valid page:
When i testing it after uploading on azure portal it shows me an error page:
Is there any specific configuration i need to do for Azure platform?
Also i have done form authentication on my web application, so when I try elmah.axd it will redirect to login page and i need to login first. I would like to remove that form authentication, particularly for elmah.axd. How can i achieve this?
The nuget package does not add the following important lines to web.config resulting in 403 error.
<elmah>
<security allowRemoteAccess="1" />
<errorLog type="Elmah.XmlFileErrorLog, Elmah" logPath="~/app_data/elmah" />
</elmah>
This should fix the 403.
Also you may want to restrict the access to error logs by
<add name="Elmah" verb="POST,GET,HEAD" path="/admin/elmah.axd" type="Elmah.ErrorLogPageFactory, Elmah" resourceType="Unspecified" requireAccess="Script" preCondition="integratedMode" />
I would like to use integrated authentication to access a SQL database from a web part. It should use the IIS Application pool identity.
By default you will get the error:
System.Data.SqlClient.SqlException: Login failed for user 'SERVER\IUSR_VIRTUALMACHINE'.
Because in web.config impersonation is set to true:
<identity impersonate="true" />
I can set this to false and the database code will work. Anonymously accessed sites will also work. Any SharePoint site that uses authentication will fail however so this is not really a solution..
To solve this would I have to encapsulate all my database access code to run with elevated priviliges, is that how SharePoint does it internally? Somehow that doesn't seem like the most performant solution.
Is that still the way to go, just use SQL security to access databases from SharePoint custom web parts?
The <identity /> and <authentication /> elements in the web.config file will together determine the account that is used in to connect to SQL Server when using integrated authentication.
When <authentication mode="Windows" /> is configured, you're deferring to IIS to authenticate users. I'm guessing that your your web.config contains:
<authentication mode="Windows" />
<identity impersonate="true" />
and that IIS is configured to allow anonymous users. Setting <identity impersonate="true" /> causes IIS to pass the identity of the IIS anonymous access account to SQL Server.
As Lars point out, using SPSecurity.RunWithElevatedPrivileges will achieve what you want. I don't believe you'll see any noticeable impact on performance but that's something you can test :-)
Use SPSecurity.RunWithElevatedPrivileges to run your code in the context of the app pool identity.
This is incorrect. Because <identity impersonate="true" /> is set to true ASP.NET / IIS will run the thread as the user that is currently logged in (so not the app pool account but the actual user logged into the website).
Something else is going on here. Could you post your connection string for the custom database? (minus the private data off course)