I have developed an api in laravel and then there is no ssl certificate installed and all working good. But after some time, I have install ssl certificate but now the api's not working in my mobile app but it's working in postman.
the response getting from you have not passed any header but in actual I have passed header.
I have just made one changes http->> https in url.
You would need to update the code in your mobile app to point to https, instead of http.
If you are hosting your API with Nginx, you can redirect HTTP -> HTTPS requests by modifying your config such as:
server {
listen 80 default_server;
server_name _;
return 301 https://$host$request_uri;
}
This will automatically redirect any HTTP request to its SSL equivalent.
Related
I have a Saas product which allows my end-user to bind their own domain to manage their products but I encountered an issue when I try to redirect those requests that is originally not requested by "http" to "https", the site will return "too many request redirection". Meanwhile, I do not want to configure port 443 into my nginx configuration as some of scenario, some of the request path might not need to neccessary to have "https". If I configured the force redirection in nginx which means all the request must served under "https" which might leads all of the request path is served via "https" but what I want to achieve is only some of the request path served under https only.
Below is the code that used to achieve the force redirection from http to https
if (!$request->secure()) {
return redirect()->secure($request->path());
}
I have a CloudFront resource sitting in front of my S3 bucket. It's accessible at —
https://<id>.cloudfront.net
but if I hit —
<id>.cloudfront.net:443
I get a 400 Bad Request. I want to point to CloudFront in my HAProxy configuration, but I can't use the 443 port because of the above-mentioned issue. Nor can I use the https URL protocol in the server statement.
backend my_cloudfront_app
http-response set-header Strict-Transport-Security max-age=31536000
server my_server <id>.cloudfront.net:443
How can I hit HTTPS cloudfront from this server block in HAProxy?
I assume You will need to add some infos to the request headers for the cloudfront backend.
This example works with HAProxy 2.0
backend my_cloudfront_app
http-response set-header Strict-Transport-Security max-age=31536000
# Add backend header for cloudfront backend request
http-request set-header Host <id>.cloudfront.net
# maybe you will need to add a S3 prefix to the request path
# http-request set-path <CLOUDFRONT_S3_Prefix>%[path]
server my_server <id>.cloudfront.net:443 sni str(<id>.cloudfront.net) ssl verify none
My questions is simple, but I cannot find an answer and I haven't got any resources to test it myself.
Can I make HTTPS CORS request from one domain to another HTTPS domain?
Can I make HTTP CORS request from one domain to another HTTPS domain?
I know that I can do HTTP CORS request from one domain to another HTTP domain, but I don't know if there is any difference when I use HTTPS.
Yes you can do a CORS request from a HTTPS domain to another HTTPS domain.
The only difference is because HTTPS is a secure origin, you can only make call to secure origin, so not to HTTP, the browser will block it with a message like:
Mixed Content: The page at 'https://example.com/index.html' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint 'http://example2.com/endpoint'. This request has been blocked; the content must be served over HTTPS.
Warning: If you allow http requests to call your https webpage, it will be insecure because it means an attacker can force requests to your https webpage with the cookies of a victim and read the answer
Beware if you still need to support IE8/IE9 and are using XDomainRequest as it does not support cross-protocol requests. As per MDN:
The origin's security protocol must match that of the requested URL. (http to http, https to https). If these do not match, the request will error "Access is Denied".
We have a Grails app on Tomcat deployed behind a Load Balancer that is terminating SSL (the load balancer then communicates with tomcat instances on port 8080). We have configured SpringSecurity to require a secure channel on all resources, pay attention to the headers from the load balancer, to force https and to map the ports from the load balancer:
grails.plugin.springsecurity.secureChannel.useHeaderCheckChannelSecurity = true
grails.plugin.springsecurity.auth.forceHttps = true
grails.plugin.springsecurity.portMapper.httpPort = 80
grails.plugin.springsecurity.portMapper.httpsPort = 443
grails.plugin.springsecurity.secureChannel.definition = [
'/**': 'REQUIRES_SECURE_CHANNEL'
]
Most of this is working correctly - redirects from within Grails are using the https protocol as expected, as well as most ajax requests.
There are some ajax requests however that are not working correctly. They all relate to results of interacting with j_spring_security* endpoints like j_spring_security_check. For example, if a user tries to login via ajax, we get this error in the browser (this is the redirect that the successful login initiates):
Mixed Content: The page at 'https://www.servernamehere.com/' was loaded over HTTPS, but
requested an insecure XMLHttpRequest endpoint 'http://www.servernamehere.com/login/ajaxSuccess'.
This request has been blocked; the content must be served over HTTPS.
The same problem happens upon unsuccessful authentication:
Mixed Content: The page at 'https://www.servernamehere.com/' was loaded over HTTPS, but requested
an insecure XMLHttpRequest endpoint 'http://www.servernamehere.com/login/authfail?ajax=true'.
This request has been blocked; the content must be served over https.
How can we configure spring security to understand that all redirects coming out of authentication events need to be https?
We were able to fix this issue by creating a custom Redirect strategy (implement org.springframework.security.web.RedirectStrategy) and replacing the default redirect strategy bean with our custom one. The custom redirect strategy examines the headers passed in by the load balancer and makes sure that the response is redirected to the appropriate protocol
I have a similar setup where I set in my Grails app secureChanel headers like this:
grails.plugin.springsecurity.secureChannel.useHeaderCheckChannelSecurity = true
grails.plugin.springsecurity.portMapper.httpPort = 80
grails.plugin.springsecurity.portMapper.httpsPort = 443
grails.plugin.springsecurity.secureChannel.secureHeaderName = 'X-Forwarded-Proto'
grails.plugin.springsecurity.secureChannel.secureHeaderValue = 'http'
grails.plugin.springsecurity.secureChannel.insecureHeaderName = 'X-Forwarded-Proto'
grails.plugin.springsecurity.secureChannel.insecureHeaderValue = 'https'
There was a bug in both versions (2.x, 3.x) of Grails spring security plugin https://github.com/grails-plugins/grails-spring-security-core/issues/395 however it has been fixed already....
I downloaded ngrok so i can test my site for http and https requests (if someone is trying to get in my site specific url and it will be a simple http request, i will deny it),
first, my localhost is working in 8080 port
I start ngrok, it gives me the following:
both at the same port, it's a problem i think, because if i do such simple route configuration in laravel:
Route::filter('force.ssl', function()
{
if( ! Request::secure())
{
return 'unsecured';
}
});
and i have this route:
Route::get('survey/payment/secured', array('before' => 'force.ssl', function(){
return 'secured!';
}));
and i do the following request:
https://75fdaa96.ngrok.com/survey/payment/secured
it thinks it unsecured and returns 'unsecured', how can i fix this?
Request::secure() relies on $_SERVER['HTTPS']. As the HTTPS is being provided by the proxy, not your webserver, Laravel doesn't know it's being served as HTTPS.
ngrok does pass the X-Forwarded-Proto header, but Laravel doesn't trust it by default. You can use the trusted proxy middleware to trust it.