I just deployed a Laravel App using Vapor, and received the following message. I don't believe that I changed anything (a few html blade lines).
Caching Laravel configuration{"message":"Argument 1 passed to
Symfony\Component\HttpKernel\Exception\HttpException::__construct()
must be of the type int, string given, called in
/var/task/vendor/laravel/framework/src/Illuminate/Foundation/Application.php
on line
1014","context":{"exception":{"class":"Symfony\Component\Debug\Exception\FatalThrowableError","message":"Argument
1 passed to
Symfony\Component\HttpKernel\Exception\HttpException::__construct()
must be of the type int, string given, called in
/var/task/vendor/laravel/framework/src/Illuminate/Foundation/Application.php
on line
1014","code":0,"file":"/var/task/vendor/symfony/http-kernel/Exception/HttpException.php:24"},"aws_request_id":null},"level":400,"level_name":"ERROR","channel":"production","datetime":"2019-09-27T13:18:45.338555+00:00","extra":{}}
The website now just shows {"message": "Internal server error"}
Did I do this, or is this a Laravel/Vapor bug?
This happens when you use gateway_version 2. As per vapors documentation, you need to use an external DNS like Cloudflare for HTTPS redirection. https://docs.vapor.build/1.0/projects/environments.html#gateway-versions
If you choose to use API Gateway 2.0 and would like to support HTTP to
HTTPS redirection, we currently suggest using Cloudflare as an
external DNS provider for your Vapor application. Cloudflare not only
provides DNS, but serves as a reverse proxy to your application and
features an option for automatic HTTP to HTTPS redirection.
After a Vapor deployment is completed, Vapor will provide you with
CNAME records for the domain(s) associated with your environment.
These records will point the domain to your Lambda application. You
should manually add these values as CNAME records within the
Cloudflare DNS dashboard.
In addition, when using Cloudflare, you should set your Cloudflare SSL
/ TLS mode to "Full". The "Always Use HTTPS" configuration option may
be found under the SSL / TLS menu's "Edge Certificates" tab.
A simple solution would be to use Gateway Version 1.
Related
I have a website called oldcompany.com. Our product name changed, and I would like to use Azure Application Gateway in front of the website, in order to rewrite the URL, i.e. access the website using the newcompany.com hostname.
There is a feature of Azure Application Gateway, called rewrite rules, that allows to modify request and response headers, documented here: https://github.com/MicrosoftDocs/azure-docs/blob/master/articles/application-gateway/rewrite-http-headers-url.md#rewrite-http-headers-and-url-with-application-gateway. The reason I want to use this feature is that it allows specifying complex conditions to rewrite a header. So I don't want to be using the Override with new host name switch on the HTTP setting, but rather overwrite the Host header of all requests going through the application gateway.
I have defined:
the listener to listen on HTTPS, port 443, hostname newcompany.com
the backend pool pointing to oldcompany.com
the rule binding the listener to the backend pool
With this configuration only, accessing https://newcompany.com results in Azure Application Gateway's 502 error page, which is expected, because the Host header in the request is still newcompany.com, which is not a virtual host recognized by the server (which is only serving requests for oldcompany.com).
So, in order to set the Host header, I have configured a rewrite ruleset associated to my routing rule. This ruleset has a rule that changes the request's Host header to oldcompany.com.
However, I still get the same 502 error page when accessing https://newcompany.com. I have pulled the request from my application gateway's access logs, and the request shows the following fields:
host_s: oldcompany.com
originalHost_s: newcompany.com
httpStatus_d: 502
which seems like the correct values for the original and rewritten hosts.
What am I missing to make this work?
Using the following stack:
AWS amplify
NodeJS
ReactJS (built using create-react-app)
When running amplify mock it automatically assigns an endpoint with HTTP (as can be seen in the terminal and the aws-exports.js file).
I am however hosting my app locally in an HTTPS environment using ($env:HTTPS="true") -and (npm start) so as to better accommodate the social sign-ins which usually require all requests to come from HTTPS even if on localhost.
I constantly have to change my env to HTTP to try out things with the mock backend instead of just maintaining everything in HTTPS.
Is there a way to let the mock backend be served over HTTPS?
I have found a partial answer.
using the chrome browser settings, select privacy and security and go to site settings.
Add the URLS you are requesting over http into the insecure content allowable section. This allows an origin of https to request over http.
I have a problem when I want to create an authentication system using VueJs as the frontend (http://localhost:8080/#/login) and Laravel 5.6 as the backend. When I try to submit login form using the api login url http://127.0.0.1:8000/api/v1/login, I get the error message:
Cross-Origin Request Blocked: The Same Origin Policy disallows
reading the remote resource at http://127.0.0.1:8000/api/v1/login.
(Reason: CORS request did not succeed).
I don't know how to solve this problem.
Could anyone here help me to solve my problem?
NOTE : I have to install laravel-cors before
This is an old question, but I'll reply nonetheless.
For me this error was caused by a self-signed certificate. If you open developer tools, select the network tab, click the call that failed CORS you can see the security tab. Click it to open it. If a cert is giving you problems the text "An error occurred: SEC_ERROR_INADEQUATE_KEY_USAGE" should be visible.
To resolve this just go to the URL that gave you the CORS error, and accept the cert manually.
Cross Origin Resource Sharing is a mechanism that uses additional HTTP headers to tell a browser to allow the web application running on one origin (client) have permission to access selected resources from a server at a different origin.
Basically, your Vue app (http://localhost:8080) needs to be allowed access to your Laravel endpoint (http://127.0.0.1:8000/api/v1/login) This is to prevent me from hitting your Laravel endpoint from my malicious website and acting like an authenticated user.
Based on the docs, you need to add 'allowedOrigins' => ['*'], but that means you're opening up your backend to all requests. That's fine if it's a public API but in this context it doesn't sound like you want that. Instead, in this case it would be 'allowedOrigins' => ['localhost:8080'], so that your Vue app can consume your Laravel server.
You have to use either localhost or 127.0.0.1 for all the requests. In general in your code you should make calls to the server by just appending the URI to the current host, without re-adding the host and port in the URI string. If you load your page from a given host, for example 127.0.0.1 and then try to make an AJAX request to another host, for example www.host.com, the request gets blocked to prevent XSS attacks
It sounds like you are running this in dev mode via webpack currently? If that is correct and your workflow is that you are going to build the Vue application and have it co-reside with your Laravel backend then you just need to update config/index.js to have a proxyTable entry that forwards webpack requests to the correct dev Laravel backend server.
This would look something like this.
module.exports = {
dev: {
proxyTable: {
"/": "http://127.0.0.1:8000/api/v1/login"
}
}
}
There is additional information available on how this works; https://vuejs-templates.github.io/webpack/proxy.html
I was stuck with this error recently while I was trying to get one of our old websites hosted via Azure (App Services) up and running again.
Reason: CORS request did not succeed was the error showing in the browser console, however, it turned that for our case the URL mentioned in the CORS error doesn't exist anymore - its referring to the old https://******.azurewebsites.net service url we had (previous hosted in Azure - App Services).
So also check that the URL mentioned in the CORS-error is in fact working.
In my case the computer was not displaying the correct date and time. When I try to view the page I would get the "CORS request did not succeed." Once I updated to the correct time and date the page displayed normally.
I had to change the base URL of axios. I didn't notice it was https://, not http://
file: src\store\index.js
change the
axios.defaults.baseURL = 'https://127.0.0.1:8000/api'
to
axios.defaults.baseURL = 'http://127.0.0.1:8000/api'
Note: Make sure it's exactly same URL and Port. You can see that in terminal where you start the laravel application (php artisan serve).
Using the routing rules as mentioned here: Set up DNS based URL forwarding in Amazon Route53
<RoutingRules>
<RoutingRule>
<Redirect>
<Protocol>https</Protocol>
<HostName>dota2.becomethegamer.com</HostName>
<HttpRedirectCode>301</HttpRedirectCode>
</Redirect>
</RoutingRule>
</RoutingRules>
I am able to see that http://becomethegamer.com properly redirect to https://dota2.becomethegamer.com but https://becomethegamer.com times out.
I thought it was the Protocol piece but realized that's the outbound rather than inbound.
This is in a bucked named becomethegamer.com and in Route 53 becomethegamer.com is an alias with the target as that bucket.
What could be causing https to not redirect?
No, it's this:
The website endpoints do not support https.
http://docs.aws.amazon.com/AmazonS3/latest/dev/WebsiteEndpoints.html
You can't redirect an https request without speaking https, and additionally, you need an SSL certificate that's valid for the hostname.
You can still do exactly what you're trying to do, but you'll need to use CloudFront in front and S3 in the back. Your S3 redirection configuration stays the same, but you'll create a CloudFront distribution, configure your domain name as an alternative domain name there, load your SSL cert into CloudFront, use the bucket-name.s3-website-xx-xxxx-xx.amazonaws.com web site endpoint (from the S3 console) as the Origin server, and point Route 53 to CloudFront instead of S3.
http://docs.aws.amazon.com/gettingstarted/latest/swh/getting-started-create-cfdist.html
I'm trying to redirect all https traffic to http using this in Sinatra
get "*" do
if request.secure?
redirect request.url.gsub(/^https/, "http")
else
pass # continue execution
end
end
However, on a custom domain on heroku, my browser shows me the error:
This is probably not the site you are looking for!
You attempted to reach www.[domain].com, but instead you actually reached a server identifying itself as *.heroku.com.
My DNS is configured with the www subdomain having a CNAME pointing to [domain].herokuapp.com as per https://devcenter.heroku.com/articles/custom-domains
Is this a DNS issue? Is buying a SSL certificate the only way to allow all https traffic to redirect to http, on heroku?
If you were going to use that code then I'd make it a before filter, as that's really what it is.
However, if you've received a request at the application layer (which is where your Sinatra app sits on Heroku) then you need a certificate because the HTTP layer (where the Nginx proxy servers that deal with this sit) has already received the request and will attempt to deal with it as a secure connection but fail/raise an error because there's no certificate. That is the message you'll get if you try and reach an non SSL page/site via the https URI scheme. You can still access the site but the user has to click past a scary warning.
The only way I know of that may work without a certificate (but looking at this answer probably not) is if you had access to the Nginx configuration and did the rewrite of the URL (and probably some headers) there.