We are trying to download attachments from RingCentral (Glip), however, we have noticed that the download URL has been changed during the last couple of days. We have tried using the Bearer Token with the new download URL to download the files, however, we have received an error with response code 503.
ERROR
503 ERROR
The request could not be satisfied.
The Lambda function associated with the CloudFront distribution is invalid or doesn't have the required permissions. We can't connect to the server for this app or website at this time. There might be too much traffic or a configuration error. Try again later, or contact the app or website owner.
If you provide content to customers through CloudFront, you can find steps to troubleshoot and help prevent this error by reviewing the CloudFront documentation.
Generated by CloudFront (CloudFront)
Request URL
dl.mvp.devtest.ringcentral.com/file/105660426
The only change necessary for the recent auth change is to add the Bearer Token to the URL. This can be seen in the update notice:
What do I need to do?
To eliminate or minimize the impact of this change, developers will need to modify their application to attach authentication credentials to all file download requests. See downloading protected content in the Media content section of the RingCentral Developer Guide.
https://medium.com/ringcentral-developers/important-changes-to-how-team-messaging-files-are-downloaded-bb13c97b3c89
A 503 HTTP Status Code is a temporary sever-side error so there's generally nothing to be done on your end but the problem should go away on its own. If you cannot wait or it's taking a long time to resolve itself, please create a support case so the team can communicate the status to you.
Here's some information on 503 errors from MDN:
503 Service Unavailable
The HyperText Transfer Protocol (HTTP) 503 Service Unavailable server error response code indicates that the server is not ready to handle the request.
Common causes are a server that is down for maintenance or that is overloaded. This response should be used for temporary conditions and the Retry-After HTTP header should, if possible, contain the estimated time for the recovery of the service.
Caching-related headers that are sent along with this response should be taken care of, as a 503 status is often a temporary condition and responses shouldn't usually be cached.
I have this proprietary code I am working on for my job.
I am writing test cases for it because the code was changed and the test cases are now broken.
It is a C# web Api MVC .Net Framework app
I have a method that I enter a string url in
Then this code executes
HttpResponseMessage response = await Client.GetAsync(url).ConfigureAwait(true);
System.Uri uri = new System.Uri(url); // convert string to Uri
var cert = System.Net.ServicePointManager.FindServicePoint(uri).Certificate;
response.EnsureSuccessStatusCode();
when it gets to response.EnsureSuccessStatusCode() , it gives a 401 unauthorized and then throws an exception not allowing my test to pass
When I try the same thing with http://www.google.com which is not an https, then
it gives a 200. So something is going on with security stuff
What are the things I need to do to get a https to give a 200? Does it need username and password credentials or something or some other token of some sort?
Also, when I test it using Rest Client DHC with the secure https link that was failing above it gives me a 200. However, I had to refresh the bearer token for it to give a 200. If I used an old token it would give a 401.
Furthermoore, when I test a different link like https://www.facebook.com (which is not the one I want to test in my application, just troubleshooting) which is secure, it works giving me a 200 both in my application above and Rest Client DHC even with an old bearer token.
If you're trying to makes CORS requests to web API, you'll need to configure It to accept cross origins requests. If you dont configure your web api to accept cross origin requests, it'll throw these type of errors when calling It. And keep in mind that for web api access, https://www.domain.so and http://www.domain.so are completely diff clients.
Look at this link:
https://learn.microsoft.com/en-us/aspnet/web-api/overview/security/enabling-cross-origin-requests-in-web-api
I am trying to wade my way through learning IdentityServer so that I can implement single sign-on at my workplace. I have a POC service running locally and when I request the configuration, this is the configuration that displays:
{"issuer":"https://localhost:44345/core","jwks_uri":"https://localhost:44345/core/.well-known/jwks","authorization_endpoint":"https://localhost:44345/core/connect/authorize","token_endpoint":"https://localhost:44345/core/connect/token","userinfo_endpoint":"https://localhost:44345/core/connect/userinfo","end_session_endpoint":"https://localhost:44345/core/connect/endsession","check_session_iframe":"https://localhost:44345/core/connect/checksession","revocation_endpoint":"https://localhost:44345/core/connect/revocation","introspection_endpoint":"https://localhost:44345/core/connect/introspect","frontchannel_logout_supported":true,"frontchannel_logout_session_supported":true,"scopes_supported":["openid","profile","email","roles","offline_access"],"claims_supported":["sub","name","family_name","given_name","middle_name","nickname","preferred_username","profile","picture","website","gender","birthdate","zoneinfo","locale","updated_at","email","email_verified","role"],"response_types_supported":["code","token","id_token","id_token token","code id_token","code token","code id_token token"],"response_modes_supported":["form_post","query","fragment"],"grant_types_supported":["authorization_code","client_credentials","password","refresh_token","implicit"],"subject_types_supported":["public"],"id_token_signing_alg_values_supported":["RS256"],"code_challenge_methods_supported":["plain","S256"],"token_endpoint_auth_methods_supported":["client_secret_post","client_secret_basic"]}
As part of this, you can see:
"response_types_supported":["code","token","id_token","id_token token","code id_token","code token","code id_token token"]
However, when I send a request to the service, with responseType=id_token in the url, I get the error message:
The authorization server does not support the requested response type.
I have tried other responseType values but still get this error message.
I am basically a beginner at web security and IdentityServer, so I am sure I am missing something very basic.
This is pretty stupid. All of the examples online I have looked at for IdentityServer show the parameter as responseTypes (camel case). I think these examples must have all been done against an older version of the platform.
The correct parameter name to send is response_types.
The list of possible parameters that you can send to the authorization endpoint are listed on the following websites :
OpenId RFC : http://openid.net/specs/openid-connect-core-1_0.html#AuthRequest
Identity server doc : https://identityserver.github.io/Documentation/docsv2/endpoints/authorization.html
The correct parameter is "response_type" and not "response_types" :)
In my ASP.NET MVC web application, I have an external single-sign-on which is used to authenticate the user centrally in the enterprise. The SSO is supposed to return a "packet" of stuff that identifies the user uniquely, which would then be used to pass to local ASP.NET Owin Cookie Authentication (or alternatively Forms Authentication, or something like that). If for some reason the SSO-provided "packet" of stuff doesn't contained minimum required info, I'd like to handle it in the local ASP.NET level appropriately. It's a pretty severe error and not necessarily something that would commonly occur. So I thought I would do something like this:
public class AuthController() : Controller
{
public ActionResult Login(string returnUrl)
{
// Process external single-sign-on authentication
bool isSuccess = ProcessExternalAuth();
if (!success)
// return appropriate HTTP status code
else
// continue with login
}
}
But I'm not sure which HTTP status code to return. Would something like this be appropriate?
return new HttpStatusCodeResult(
HttpStatusCode.BadGateway, "SSO authentication failed.");
According to List of HTTP Status Codes, one of the 500 errors would probably be most appropriate:
Response status codes beginning with the digit "5" indicate cases in which the server is aware that it has encountered an error or is otherwise incapable of performing the request...
Error code 401 and error code 403 are typically used for authentication related errors. These however have some standards that go along with them that specify when and how they should be used. In your instance neither of these would quite fit. For example, a 403 is described as (http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html):
403 Forbidden
The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the entity. If the server does not wish to make this information available to the client, the status code 404 (Not Found) can be used instead.
A good alternative would be to return code 503 (service unavailable).
503 Service Unavailable
The server is currently unable to handle the request due to a temporary overloading or maintenance of the server. The implication is that this is a temporary condition which will be alleviated after some delay.
Errors authenticating clients should be under 401:
401 Unauthorized (RFC 7235)
Similar to 403 Forbidden, but specifically for use when authentication is required and has failed or has not yet been provided. The response must include a WWW-Authenticate header field containing a challenge applicable to the requested resource. See Basic access authentication and Digest access authentication.[36] 401 semantically means "unauthenticated", i.e. the user does not have the necessary credentials.
Note: Some sites issue HTTP 401 when an IP address is banned from the website (usually the website domain) and that specific address is refused permission to access a website.
https://en.wikipedia.org/wiki/List_of_HTTP_status_codes#4xx_Client_Error
I´m getting a problem sending the authentication request with activated attribute exchange. It works with FF and Opera but IE seems to have a problem with it.
The error occurs within the request.RedirectToProvider(). The Url within the address bar shows the endpoints url.
Here is a code snippet where the authentication request is created and sent
using (OpenIdRelyingParty openid = this.createRelyingParty())
{
IAuthenticationRequest request = openid.CreateRequest(openid_identifier, realm);
;
var fetch = new FetchRequest();
fetch.Attributes.AddRequired(WellKnownAttributes.Contact.Email);
request.AddExtension(fetch);
// Send your visitor to their Provider for authentication.
request.RedirectToProvider();
}
I guess that inside RedirectToProvider() a POST is sent and short after a GET. By RFC a POST followed by a GET is not allowed. Unfortunately I don`t know how to validate it.
Does someone got the same problem?
On further investigation this seems to happen (based upon the providers logs):
The authentication request is sent via POST. The Provider answers with a redirect. This is how it happens that there is at first a POST and then a GET.
I dont think this is how the openId specification say to do it. Shouldnt there be a POST response if i request with a POST and a GET if I request with a GET?
Anyhow.. Is there a way to make the RedirectToProvider()-method sending the request via GET instead of POST?