I have a similar issue to this post.
I am following the 3-legged tutorial on the Forge API website here, and I matched the callback URI and URL, tried swapping the data:read for viewables:read, and tried switching to https:// and not http:// but I'm still getting an error when I run the app and login via the link in the tutorial which I adjusted with my information.
The error I get is:
Not Found.
The requested URL /parking/oauth/callback was not found on this server.
Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.
Do you know what could be wrong?
Related
I have a SPA made with React JS on a S3 Bucket and I’m using Cloud Front to work through HTTPS and with a custom domain. When I refresh the page - if I have another Route that is not the BASE_URL (for example domain.com/something), S3 sends me a 404 error.
I also tried redirecting the error page to BASE_URL but it doesn’t work, it redirects me to the Http default domain that S3 provides me and again, it gives me an 404 error page.
I don’t know if there exists an alternative way to keep the URL without any change (domain.com/page) and avoid the 404 error the way a web server (apache) handles.
If you are using CloudFront to host s3 website, the effective way to get rid of 404 on reload of non-index route like www.google.com/about or similar non / is by the following steps:
Go to your CloudFront distribution
Go to Error Pages
Create a new error page with the following params:
HTTP Error Code: 404
TTL: 0
Custom Error Response: Yes
Response Page Path: /index.html
HTTP Response Code: 200
enjoy
credits going to this article https://gist.github.com/bradwestfall/b5b0e450015dbc9b4e56e5f398df48ff
You have two options. Either use CloudFront error page as a catch-all that redirects to / (you mentioned you tried setting an error page but did not detail what you did. This should work). The downside is that it will respond with the HTML page for all not found paths, even for mistyped CSS paths, for example.
The other solution is to use Lambda#Edge to rewrite the origin request path. This is a more customizable solution and you can define which paths you want to redirect to the root.
when i type http://profilepics.in its my website i am getting 404 not found error. Here is the link : https://profilepics.in/error-page.jpg.
When i type https:// its working fine. I am using cloud flare please help me to get rid of this.
I'm trying to integrate my single page React app with GitHub.
I successfully run first stage of authentication, i.e. receiving redirect with code from https://github.com/login/oauth/authorize
The problem is the second part, i.e. POST to https://github.com/login/oauth/access_token
I can't do POST or GET from my web page itself via JavaScript or JQuery. Using $.ajax or $.post all end up with error Access-Control-Allow-Origin.
The app was created with create-react-app and run with npm start.
How can I avoid Access-Control-Allow-Origin error in my scenario? Is there a way to get GitHub token for GitHub API in some other way?
I've tried to do POST with , and it does not complain on Access-Control-Allow-Origin. In fact after .submit() I receive expected response (as per https://developer.github.com/apps/building-oauth-apps/authorizing-oauth-apps/#web-application-flow) but it comes as a file, which Chrome immediately downloads.
I am using server side google oauth in angular.js,
Suppose my redirect url is localhost:8000/redirect. To remove # in angularjs I am using
$locationProvider.html5Mode(true);
But, when i visit the url I get an error :
Error response
Error code 404.
Message: File not found.
Error code explanation: 404 = Nothing matches the given URI.
However if I type the url manually i.e localhost:8000/#redirect then I get what I expected and then redirects to localhost:8000/redirect
I have also tried to add # from Google app console. But, that is not allowed.
So how to remove hash completely ?
I've searched around for this quite a bit and found similar questions but not exactly the same, but nonetheless I apologize if this is a duplicate question.
Basically, I am trying to handle HTTP error responses (i.e. 404) with a custom error page (i.e. 404.html) when my application is down, but weblogic is still up.
I am using Apache 2.2 with the weblogic module. I have set the ErrorDocument directive for Apache as well as the ErrorPage parameter within the block.
I have also set the location within my web.xml for my application, but this question is for when the application is down.
Currently, when the app is down and weblogic is running I am getting the weblogic default 404 page. How can I force apache and/or weblogic to use my custom page?
Here is a sample of one variation of the config that I have tried.
<IfModule mod_weblogic.c>
WebLogicCluster host:port,host:port
KeepAliveEnabled ON
WLProxySSL OFF
Debug ALL
ErrorPage http://host:port/errors/errorSystem.html
</IfModule>
I can access the error page directly, but traffic is never forwarded on error.
I've also tried to set the ErrorPage to a relative url which is the ideal solution.
The explanation from apache.org do it also with samples of code:
ErrorDocument 500 http://xxx/
ErrorDocument 404 /Lame_excuses/not_found.html
ErrorDocument 401 /Subscription/how_to_subscribe.html
According to WebLogic documentation, with ErrorPage parameter, "The plug-in redirects to an error page when the back-end server returns an HTTP 503/Service Unavailable response and there are no servers for failover.".
So 404 error from WebLogic will not be redirected to our custom error page specified with ErrorPage parameter.
The workaround is to create a simple webapp and deploy it onto your WebLogic. In this webapp:
in [web.xml] Specifiy your custom error code and page mappings, e.g.:
<error-page>
<error-code>404</error-code>
<location>/errors/404.html</location>
</error-page>
in [weblogic.xml] State that your context-root is '/':
<weblogic-web-app xmlns="http://www.bea.com/ns/weblogic/90" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<context-root>/</context-root>
</weblogic-web-app>
Your need to have error pages in place such as in '/errors' folder of you webapp.
Note that the 'FMW Welcome Page Application' might have already been deployed and using '/' as context-root in your WebLogic domain. If that is the case, I believe it is safe to undeploy it or untarget it, but you are advised to raise a SR to product support asking whether it is hardful to do so.