I get a 500 internal error when i try to add a custom domain to appwrite 1.2.0 server.
I have changed .env variable _APP_ENV and _APP_DOMAIN_TARGET to "api.example.com"
I have also followed manual ssl generation method here
When i navigate to my domain "api.example.com" i can access the console with no other issues and certificate in toolbar show connection secure certificate is valid.
However when i try to login to my app i get an error in console: Access to XMLHttpRequest at ... from origin 'https://www.mydomain.0r' has been blocked by CORS policy: The 'Access-Control-Allow-Origin' header has a value 'https://localhost' that is not equal to the supplied origin.
I assume this is because i am unable to set the custom domain in appwrite console but cant figure out what is causing the 500 error
Related
I was trying out the curity configuration for an authentication service and a token service for OAuth and OpenID Connect locally. After all the configuration, when I was trying to test it with OAuth Assistant, I get an error:
Bad request
The request could not be processed
In the terminal, I can see these two INFO logs for particular
se.curity.identityserver.util.AllowedFrameOriginUtils - Requested origin is not allowed: 'http://localhost:...'
se.curity.identityserver.controllers.authorize.AuthorizeOAuthRequestModelProvider - Could not establish the redirect uri for request and client www. If this error occurs *after* being redirected to the authentication service and back, then this error has probably occurred because the original session cookie has been lost. Ensure that the cookie named 'sessionid' was sent to the authentication service. If not, check that the user's browser is not withholding it (for example by the cookie jar becoming full) and that a reverse proxy is not interfering with it.
There is no issue with sessionid. Anyone know how to fix this issue?
https://inspector.swagger.io/builder
I have an api hosted locally and needs a client certificate for authentication. I am able to access the API from Fiddler and Postman. For both these I could add the client certificate needed to authenticate with the api. I am not sure how I can provide this client certificate to swagger inspector. Any idea?
I see following error message:
The request has been terminated.
Possible reasons for the error:
Network error: the host is unreachable
Certificate problem: https is specified, but the service is using a self-signed, expired, or otherwise problematic certificate
CORS error: the requested service does not allow requests from other domains. Please try adding the Swagger Inspector Extension in chrome, since it can resolve this issue.
The Swagger Inspector Extension may be disabled. Please try enabling it by going to: chrome://extensions.
I am creating an iOS webview and I am using the WKWebView class.
The main page consists of a user login page however when I enter my credentials I am redirected to a blank page with this message:
Misdirected Request This client needs a new connection for this requested host name does not match the Server Name Indication (SNI) in use for this connection.
Could it be because the request is being made to a different domain (i.e. the backend) ?
Thanks
The issue was due to SSL Certificates. i.e. separate SSL certificates needed to be issued for the front and back ends.
I think we just discovered a bug on iOS 9 (version as of Oct 23rd 2015) when using client SSL certs to talk to a backend API. In common with a lot of REST services, our API generates 4xx error codes to communicate status. One of those is a 403 Forbidden error when a client tries to access paths that a specific client ID is not authorized to access. Note that this HTTP error occurs AFTER the client SSL cert has setup a valid connection & and the client ID has been authenticated.
In iOS 9, this sequence will generate an invalid client SSL error:
FAILED: Error Domain=NSURLErrorDomain Code=-1206 "The server “our.server.here” requires a client certificate."
(note: this a followup to my tweet here: https://twitter.com/ckmaresca/status/657576686318256128 - I figured SO is the place most people will search for this)
It took us days to finally figure out but it turns out that this particular error is generated by Apple's new Application Transport Layer security. Specifically, it seems that if you are using client certs and your backend API generates an HTTP 403 error, ATL believes that the cert is bad and kills the entire transaction.
We know this because we can see in our server logs that the request goes through and executes properly. We've also observed that the socket stays alive trough the request and this error only shows up after the response from the server is received. We also know our client cert works since any path not returning a 403 works with zero errors and changing the HTTP error code to 401 makes this problem go away.
This is problematic for a number of reasons, but mostly because HTTP errors are not SSL errors. The two can operate independently and it's perfectly possible to have a 403 error with a valid client side SSL certificate....
The work around is to change all your 403 errors to something else. I would note that a large number of Oauth1/2 servers will generate various 403 errors, so this might be non-trivial. Alternatively, it might be possible to use a reverse proxy to remap HTTP 403 errors to a different HTTP code - we have not tested this.
We have filed a bug with Apple, but I wanted to give people a heads up so maybe they can avoid banging their heads against a wall like we did for a week....
Thanks to the Sherbit.io enginnering team (specifically Varun & Matt) for debugging this.
I have a Rails 4 app on Heroku and I just pointed my custom domain to the app. I am able to access the app through the custom domain but when I try to sign in I get an error: "The change you wanted was rejected. Maybe you tried to change something you didn't have access to." on the Heroku page and the Heroku logs give this error: Can't verify CSRF token authenticity. I am still able to sign in through the appname.herokuapp.com url. I haven't yet purchased a SSL certificate for the new url. Could this be causing the error?