How to disable the web security in Firefox or how to solve CORS issue in Firefox during development?
Things tried but did not work:
The option of filtering in "about:config" and setting the "security.fileuri.strict_origin_policy=false" doesn't work
Tried few add-ons like "CORS-Everywhere" (https://addons.mozilla.org/en-US/firefox/addon/cors-everywhere/). Doesn't work.
How to disable the web security in firefox
Don't. It gives unrealistic results for testing.
how to solve CORS issue in Firefox during development
Ideally: Create a development environment that is just like the live environment.
The server side code will, at some point, need development work performed on it. Your team will need the ability to create a development server with test data in it for that. Use the same development server for working on the client side code.
That way you can do you development work:
without making test calls to the live server (so you never need fake test users doing fake actions on the live server with the risk that test data will escape somewhere end users will see it).
without cross origin issues (because your development server for your client side code will be the same as the development server for the URL you are requesting)
able to use relative URLs
with a browser that acts like the browsers used by end users
As a quick and dirty hack which doesn't have most of the benefits of using a proper test environment: Use a proxy server that maps requests to the same origin as your development environment to the live environment.
I used Charles proxy for that before I moved to having proper development environments.
Related
I'm developing a GraphQL API on Laravel for mobile and web applications. One of the frontend developer asking me to disable CORS on the server side because he cannot work with the API due to CORS problem. The Vue application on his localhost is making requests to my Test API which is on a URL.
From what I understand this isn't problem for the server side, CORS is s security measure for the server. I believe for development Vue developer need to handle this problem with adding a proxy to his localhost.
You are both responsible to get the application done and pointing fingers at one another does not solve this problem. This is not a technical problem.
Adding a proxy to the frontend development environment is one way to solve this problem. Another way is to whitelist the domain they are working on, or even putting a wildcard in there as the frontend developer suggested. CORS is a security feature, but it is meaningless for a development environment that does not contain any production data. Being able to get a development environment up and running without jumping through a lot of hoops helps productivity.
Work together. Your responsibility is to create an application, and without a frontend you are also failing at your task of delivering that application.
I am using Next.js and Axios libraries.
My axios requests look like this:
axios.get('/api/users/1')
This worked while I had API and rendering server inside same instance.
But now my API backend is fully separated.
While in dev mode, it is hosted at localhost:3001 while frontend (next) dev server is hosted on localhost:3000. In production rendering server is hosted at https://example.com while API is hosted at https://api.someoherdomain.com.
How to keep axios requests clean (without importing stuff and prefixing url string by hand), keeping them like /api/users/1 but automactially making them localhost:3000/api/users/1 while running development mode and https://example.com/api/users/1 while hosted in production.
I need something like https://github.com/zeit/next.js/tree/master/examples/with-custom-reverse-proxy but to work on both production and development mode.
Not a recommended approach to production scale (hence
explicit dev flag) as we should scope proxy as outside UI applications
and have separate web server taking care of that.
If this is not possible, I am looking for the most elegant way to handle this. Any suggestions?
In production we use Plesk (which uses Ngnix).
You could create an axios instance and set the baseUrl parameter based on a environment variable :)
Documentation here: https://github.com/mzabriskie/axios#creating-an-instance
We have a product which relies on a thin client installed on users machine. We make an ajax get request to a domain pointing to local host which has a real ssl. This fails in edge, works in every other browser including IE11. Note that same works if there is no ssl involved. It also works on Windows 10 Home edition.
Adding a datatype, content-type or request method does not resolve this. Only way to fix this seems to be running following command.
CheckNetIsolation LoopbackExempt -a -n="Microsoft.MicrosoftEdge_8wekyb3d8bbwe"
If this is expected behavior, can someone explain why microsoft would block this on a enterprise version but it works on home edition ?
Microsoft Edge, and Windows 10 apps in general, use AppContainer Isolation:
Isolating the application from network resources beyond those
specifically allocated, AppContainer prevents the application from
'escaping' its environment and maliciously exploiting network
resources. Granular access can be granted for Internet access,
Intranet access, and acting as a server.
Your thin-client is running on win10 enterprise edge against an intranet ssl service (localhost), so access is by default restricted by this mechanism. With the command
CheckNetIsolation LoopbackExempt -a -n="Microsoft.MicrosoftEdge_8wekyb3d8bbwe"
you are disabling network isolation on that host for the loopback network adapter (localhost) for MS Edge so your app client (and any other locally sourced app) can run on it without restriction against any localhost service.
This fails in edge, works in every other browser including IE11.
They clearly wanted to improve the default security policy of previous versions. It's never too late, MS :) There is actually an Enhanced Protected Mode (EPM) that could prevent your app from running on IE too. Chrome has its Google Chrome Sandbox that can also be tuned like this. Safari and Firefox also have sand-boxing features although I am not familiar with their particularities.
Note that same works if there is no ssl involved.
Typically, if you are using ssl is because you are dealing with sensitive data and/or a critical service. If you are not it is ok to be more lax. Again, just a matter of security policy.
It also works on Windows 10 Home edition. If this is expected behavior, can someone explain why microsoft would block this on a enterprise version but it works on home edition?
Enterprise versions of any product are known to be more restrictive since their target users are more security concerned (IT people typically don't want to expose their company's intranet payroll db service to external attackers, and things like that). Also, in this case the default behavior can be easily defined/altered by experts on the IT department (check out domain security policies) so it's better to leave the default settings to "paranoid" mode and let the experts tweak according to the company's needs.
Note there are other mechanisms at work when you are running a thin client on the browser that make this kind of protection redundant (same domain policy, XSS protection and so on). Nevertheless one can never be too safe: There are ways to work around those defenses such as Self-XSS that require isolation between the browser and the local network to avoid compromising the system. In the end, less exposed surface means less attack vectors, so isolation is good if you can afford it :)
I am a newbie at play, and I am trying at least to use HTTPS on a login and sign up pages in order to have more security on sensitive user data.
I have a range of questions regarding this:
I have configured my play application to use https on the application.conf file with the https.port property. However in my development environment I cant seem to start the server with https capability unless I use the command: play -Dhttps.port=<port>
Why does this happen? I would think that I could use a dev.conf (right now is the application.conf) file in order to do this. Can't I start the server in dev mode while using this kind of settings specified on the configuration file?
Although I start the server with https capabilities, what is the correct way to use https on play? I already created a java key store that I use, and tried to redirect (from a controller) requests to a https url using redirect(securedIndexCall.absoluteURL(request, secure)). But it does not seem to work at least on my dev enviroment (localhost). The logs specify exceptions like:
java.lang.IllegalArgumentException: empty text
java.lang.IllegalArgumentException: invalid version format: M¥å/=<junk characters continue>
Should I use https on the whole application, or just securing the login and sign up requests is sufficient?
I feel the official documentation provided is rather insufficient and I am at a loss here trying to figure out how I should do this.
Any help would be really appreciated!
I agree with Fernando, I think it's easier to set up a front end web server. In my case I used Lighttpd and it was fairly straightforward to set up. I'd recommend:
Configure Lighttpd as per these instructions (at this stage, don't worry about HTTPS just get HTTP working): http://www.playframework.com/documentation/2.3.x/HTTPServer
Then configure HTTPS in Lighttpd: http://redmine.lighttpd.net/projects/1/wiki/HowToSimpleSSL. If you intend on buying an SSL certificate then there will be a few more options to set (e.g. intermediate certificate). The following page has more information: http://redmine.lighttpd.net/projects/1/wiki/Docs_SSL
Answers to your main questions:
1) Enabling HTTPS in Play
Yes, you have to explicitly say you want to use HTTPS when starting up
http://www.playframework.com/documentation/2.3.x/ConfiguringHttps
2) The "java.lang.IllegalArgumentException" error message
There might be an issue with the keystore. This SO article seems to discuss in more detail: Play framework 2.2.1 HTTPs fails on connection attempt
3) SSL for login page or whole app
Personally, I would go for the whole app. If you're taking the time to set up HTTPS I think you might as well cover the whole site. I guess there are slight performance overheads in running HTTPS but realistically it's not something you'd notice.
You should use a front end server for HTTPS, and use HTTPS for the whole application.
Please see Setting up a front end HTTP server and see the commented out nginx settings.
I have the following problem to solve:
I few months ago I startet a website where you can watch youtube videos which aren't available in your country. Everythings works fine but now I want to offer a new method where I route all the requests directly over my server. Therefore I will later use a custom DNS-Server. Right now I use the hosts file for testing but I have really no idea how i can identify the user. I can promp the user user to login on a website but I will that it works systemwide so if he use a youtube downloader for example it have to work there either and not only in the browser where I could use a session system with cookies. I want a solution where the user can identify himself once in a time like a website or something like this but how can my server detect if this is a user which is logged in or if he is not?
There are several ways that this could be accomplished with varying levels of difficulty.
standard proxy server over https. Your service could simply be a proxy server and then every "client" would update their browser to point to your proxy server. You could also simplify this by using a proxy PAC file (proxy auto config).
An anonomyzing interface. The end user would not be able to use their standard search tools etc, instead they would have to use a web page much like what google translate does.
A browser plugin. There are already firefox plugins which do something similar to this. They change the way that the browser resolves DNS. This may be the best bet for you but would require development work.
An actual install utility that you have your users install on their machines which update the dns servers.