I'm using Azure mobile services with .net backend. My API controller works OK on my pc but as soon as I deploy it to Azure, Upon pinging from Postman gives "Authorization has been denied for this request." message with HttpStatusCode 401
Note that... I'm using table storage for storage instead of SQL Server and in the process removed all of Entity Framework related code. Also, None of the endpoints do not require any authentication.
Thanks.
The default authentication for mobile services is anonymous (i.e., no authentication required) when running locally, and application (i.e., at least the application key needs to be supplied).
If you're using Postman, try adding a "x-zumo-application" header to the request, with the application key (which you can get in the Azure portal) as the value. The request should work then.
Related
Running into issues with multiple instances of IdentityServer4 on Kubernetes exposed by the load balancer. I dont think there is a issue with credential login, my issues are around JWT Tokens. Works fine when there is only 1 instance.
Overview:
IdentityServer4
MongoDB Data Storage
PersistedGrantStore
Data Protection setup on Redis
Multiple .Net Core 3.1 Web API. Using AddIdnetityServerAuthentication in start up passing in the connection and the API Name. I am running multiple instance of the API. Reducing down to 1 I still get the same issue. Works fine if there is only 1 instance of the Identity Server but multiple instances I get the following error on the API:
"Bearer" was not authenticated. Failure message: "IDX10501: Signature validation failed. Unable to match key:
I am not getting any errors or failed authentications on the IdentityServer logs.
So the questions going on in my head is, JWT token so in I believe the request should be validated by the token, i.e. the API should not be requesting info form the Identity Server? Identity Server has DataProtection setup running on Redis as its store, I can see its dropped info in there. I have persisted grants store, but tokens are not added.
Do I need to switch to resource vs JWT? What is likely overhead for that?
Are the tokens not getting shared between the API instances via Data Protection?
Thanks for any advice / suggestions.
In case anyone else comes across this. It was down to mistakenly leaving developer signing in the config of Identity Server. Replaced with a certificate solved the issue.
builder.AddDeveloperSigningCredential();
to
builder.AddSigningCredential(rsaCertificate);
I am getting a 401 and some cross domain issues when trying to access IBM Weather REST API from either client (browser) or server.
If I generate a URL and try and access it directly from a browser (eg paste it in it works fine and the JSON weather report is returned).
When I try and run the Javascript HTTP request from either the browser or server it seems like it's only allowed to run from an ibm.com domain.
Failed to load https://twcservice.au-syd.mybluemix.net/api/weather/v1/geocode/-33.00/151.00/forecast/daily/7day.json?units=m&language=en-US: The 'Access-Control-Allow-Origin' header contains multiple values 'https://*.ibm.com, https://*.ibmcloud.com', but only one is allowed. Origin 'http://localhost:3000' is therefore not allowed access.
I am using the free service on Bluemix. Is this restricted to only run via a Bluemix server? or are there some options I can pass when I create the service on Bluemix
Note, when I make the request I am using the credentials supplied via the Bluemix console. Again, this works via the browser URL bar, but not via code.
Update/More info: if I hit past the URL above into the browser (with creds) it works as above, then if hit it via the web app in the same session it works.
Hmmm. So the IBM server is sending the following response header:
Access-Control-Allow-Origin: https://*.ibm.com, https://*.ibmcloud.com
That's an invalid response from IBM. Unfortunately, I think your only option is to complain to IBM, and convince them to
Return a valid Access-Control-Allow-Origin response header (with only one value)
Allow people outside of IBM to access it
Without that, I fear you're out of luck.
We have a Mobile backend Service API crated and deployed on Azure. This app makes an external http call to an API using httpClient.GetAsync.
The call works well and returns expected result while running locally, but after publishing on Azure it throws 403(Forbidden) error.
403(Forbidden) is a common error. Please contact the API provider and check whether there are some restrictions of accessing the AP. For example,
Only specific IP addresses(whitelist) can access the API.
The API need to verify the client certificate.
After going through walkthroughs I had a test mvc app, test web api, and identityserver3 all working perfectly on my machine. I deployed IdentityServer3 to our servers in AWS behind a load balancer. I followed all the instructions in the Deployment wiki. I am able to hit the .wellknown configuration fine after deployment from a browser on my machine.
I changed the authority url for the mvc and api test apps to point to the aws deployment. Clients, Scopes, users, etc are all configured identically as they are hitting the same database as it was when running on local machine.
I can get an access token using RequestResourceOwnerPasswordAsync just fine so I think ids is installed fine.
However, both the API and the MVC app just trying to use implicit flow are now failing. FOr instance, when I try to hit a mvc controller action marked with [Authorize] I get an error stating "An invalid request URI was provided. The request URI must either be an absolute URI or BaseAddress must be set".
If I try to hit the webapi from the mvc app (both running locally on my machine) after a successful RequestResourceOwnerPasswordAsync call, I get the error "Response status code does not indicate success: 401 (Unauthorized)." after what seems like a timeout.
Any help would be greatly appreciated.
Figured out the problem. When specifying PublicOrigin, it has to be a full URL and not just the domain. I had left off https:// prefix.
The web api issue was related to connectivity to the identity server. There was some incorrect proxy settings for the app.
I'm trying to use an Office 365 organizational SharePoint site as a storage point through the SharePoint REST API for docx files generated in a Rails app. I've registered the app through https://<domain>.sharepoint.com/_layouts/15/appregnex.aspx and obtained a client_id and client_secret. Using https://<domain>.sharepoint.com/_layouts/15/appinv.aspx, I gave the app the following permissions:
<AppPermissionRequests AllowAppOnlyPolicy="true">
<AppPermissionRequest Scope="http://sharepoint/content/sitecollection" Right="FullControl" />
</AppPermissionRequests>
Using the oauth2 gem, I've so far managed to obtain an access token using client_credentials:
client = OAuth2::Client.new(<client_id>, <client_secret>, site: "https://<domain>.sharepoint.com", token_url: "https://login.windows.net/<tenant_id>/oauth2/token")
token = client.get_token(grant_type: "client_credentials", client_id: client.id, client_secret: client.secret, resource: "https://<domain>.sharepoint.com")
The client_credentials strategy seems to work, as a token is received. However, trying to use it results in failure.
token.get("/_api/web/title") returns OAuth2::Error: { "error_description" : "The server was unable to process the request due to an internal error. For more information about the error, either turn on IncludeExceptionDetailInFaults (either from ServiceBehaviorAttribute or from the <serviceDebug> configuration behavior) on the server in order to send the exception information back to the client, or turn on tracing as per the Microsoft .NET Framework SDK documentation and inspect the server trace logs." }
RestClient.get("https://<domain>.sharepoint.com/_api/web/title", { "Authorization" => token.token }) returns RestClient::Unauthorized: 401 Unauthorized
I'm pretty much at my wits' end over this, and I'm this close to telling my boss that if it can somehow be done, I'm simply not knowledgeable enough to do it.
The IncludeExceptionDetailInFaults is a wcf service setting in the endpoint applications web.config. If you have access to the server https://.sharepoint.com then you can turn that on momentarily. Basically, this will send the exception trace dump to the client in the response. By default, any 500 status errors will come back with no information except for ...ooops an error occurred.
I don't know how that server is configured or that much about SharePoint at all. However, the error could be anything imaginable and not even related to oauth. Unless you can get the server log or have it spit back the exception then you are going to be spinning your wheels.
Very likely you don't have sufficient permissions. Try with different scopes.