I already enabled sandbox mode, but still not allowed to save changes without https canvas url. This makes it a lot harder to test any canvas page related changes.
Just enter the same URL as your app, and add in https instead of http. It should still use the HTTP URL providing you are using Facebook over a non-secure connection.
Related
I am developing an app for shopify. The app will provide pages and functionality for the Shopify Admin area, specifically using App Bridge.
The app bridge URLs look like this:
https://[shop].myshopify.com/admin/apps/[my-app]/[my-path]
When you visit this page it loads shopify header/footer/menu, also an IFrame pointing to [my-path] on my site, for example:
https://example.com/[my-path]
I would like to setup Ajax requests using the same system of URLs. for example I would use the endpoint as follows (I know this one doesn't exist, just an example):
https://[shop].myshopify.com/admin/apps/proxy/[my-app]/[my-path]
Then instead of rendering the IFrame with my URL, Shopify admin would proxy the request, forwarding it to:
https://example.com/[my-path]
Is this possible, or do I have to send the Ajax request directly to my own server? If the later, how is it recommended I do authorisation? Can the HMAC that came in the original request be forwarded to the AJAX request (seems that would be bad, but not sure exactly why), or use a session that I establish on the original request?
You setup an App Proxy in your App. You provide an endpoint in your App for the Proxy. Once this App is installed in a store, you can now call your App from the store itself, to the Proxy. Securely. That is the whole point of the App Proxy.
In my Controller, which is build with using spring-boot, I've enable CORS only for my server and localhost whit this annotation:
#CrossOrigin(origins = {"http://localhost:8080", "https://www.somepage.com"}, maxAge = 3600)
This is working fine. But now I'm not sure, if it's also needed, to add basic authentication for the REST API. As far as I understood, the only call the REST API is accepting now, is my own server and localhost, and that's why, I think it's not needed. But I was not able to figure out, if this is a bad practice or not.
Do You recommend to use basic auth too for the REST API even when CORS is enabled?
No.
The Same Origin Policy is a feature built into browsers that prevents an attacker's JavaScript running on the attacker's website from reading the response to an HTTP request from the victim's browser to the targetted website.
This stops the attacker from stealing data from the targetted website using the credentials belonging to the victim.
(To some degree. There are other kinds of attacks.)
CORS is a tool that relaxes this rule so that when you to allow another site to access that data (either using the user's credentials or because it is just public data), it can.
Note that I said "a feature built into browsers". It isn't built into other tools.
An attacker can still make HTTP requests with their code, or tools like Postman and curl, or their own web browser.
Neither the Same Origin Policy nor CORS are substitutes for authentication and authorization.
CORS is a mechanism implemented in browsers and it will not prevent me to access your API with curl. Therefore, secure your API if you need it to stay secure.
I'm using basic authentication on my site, which does a simple windows popup asking for username and password. I'm wondering if there's a way to redirect http traffic to https traffic before this popup? Currently, i'm using a custom redirect error page, so when someone goes to http://www.mysite.com/ the popup comes up and asks for username password, and after they enter it the page redirects http traffic to https. But i'm assuming that password is sent in clear text, since the redirect is happening after the login attempt.
I've tried playing with IIS, and javascript on the page itself, but it seems the popup is happening before any of that comes into play. Is there anyway to redirect before that popup comes up?
Thanks!
I know this is old but here is how I managed to achieve this for anyone who would need the same.
Remove the HTTP bingind on the target domain's virtual server
Create a second virtual server for the same domain with only HTTP binding
Add a rewrite rule to the new virtual server that redirects all trafic to the HTTPS version of the domain
This is the only straight forward way i found and it is probably the simplest.
Voila!
I have read on some blog (sorry for not mentioning the reference but I can't find it anymore) that you will lose all your work on securing your site if you redirect a user from an https page to an http page.
So, could someone please explain to me if I am right or wrong here in the following scenario:
Is it right practice to use https on the login page then redirect him to Admin Page with http, or will this will create a security issue like Session Fixation hijacking, stealing session, etc.?
Or must I keep the Admin Page also in https?
Another side of the question is: will https allow caching of static files?
I have read other articles here but I am still confused as some say 'yes' and some say 'no'; also some say it depends on browser.
In your instance (in only securing the login page with HTTPS) while login details will be protected (e.g. username/password), your users will be susceptible to Session Hijacking.
Whether you use a mixture of HTTP/HTTPS or full HTTPS depends on your situation. Amazon for instance, will use HTTPS for the login, but you'll browse the site with HTTP, but as soon as you go to a sensitive area (Order details screen, change account/password details etc.) it switches to HTTPS and asks you to re-authenticate. Re-Authenticating the user after switching from HTTP to HTTPS is the key to stop Session Hijacking because you're effectively issuing a new Session token. So if a user steals the session token, they still don't have your username/password and can't access your account section.
If the admin area is particularly sensitive then just HTTPS the whole thing. Google found the overhead from using full HTTPS was between 1-5% overhead on the CPU, hardly anything basically.
As for caching static files on HTTPS I'm not sure, but this SO post suggest it'll cache as normal Will web browsers cache content over https
Everything must be used with https. If you switch over to http, everybody can see the content being sent, which means those security issues you mentioned will emerge.
The reason is that you have to identify your client in order to assign access rights in your admin site. One possibility to do so, is sending back a token (some hash or whatever). Depending on the token you know if it's an authenticated client or not. But everybody else does see this token => security issue.
Of course you could use the previous https session to exchange a private key. And use it to encrypt your http stuff somehow. But this is a bad idea, since https does this much more conveniently..
We have an implementation understanding with a merchant to create our domain cookies when user is on his site. Now in FF assuming that third party cookies acceptance is set we are able to create the cookies and flow works fine. But the issue is that after the cookie is created and third party cookie is disabled later - the request to load an image from merchant site page to ours site - we do not receive the cookie details.
Is it an expected behavior or we need some special mechanism to get the cookie?
Please help.
You may already know this but cookies are domain based. You can only access cookies on requests for the same domain.
If your image is displayed on sample.com and your the url of the image is sample.com/img.jpg then when the request is made for the image the cookies will be sent along with the request.
On the other hand if the image is displayed on sample.com and the image url is yoursite.com/img.jpg then you won't receive the cookies for sample.com.
Also, dev.sample.com and sample.com are different domain names.
Hopefully this helps clarify why you can't receive cookies. This behavior is mainly security related to prevent websites from sniffing cookies from other sites.