5 ms·

This can be helpful in development scenarios. I’m supporting a team that uses localstack to support local development against some AWS services. Unfortunately,

This can be helpful in development scenarios. I’m supporting a team that uses localstack to support local development against some AWS services. Unfortunately, the CORS settings for localstack break the development environment. With Chrome allowing them to disable from the command-line, I can provide a shortcut to launch with degraded security, no plugins, no user settings, etc. My only wish is that Chrome would make it more obvious that it’s running with these protections disabled.

chipperyman573 8y ago
>My only wish is that Chrome would make it more obvious that it’s running with these protections disabled. I know this is beginning to become off-topic, but why? Presumably, if you're using a flag that has to be run from the command-line, you're either doing it on purpose or using hardware you don't own (and a keylogger is a much greater risk than anything else at that point)
- Stratoscope 8y ago
  I can't speak for OP, but for me the problem is that I likely already have normal Chrome windows open when I start a "special" Chrome instance with a private profile and other settings. So now when I see a Chrome window I would like to be sure whether it's my normal user profile or the special profile. In practice, it's not a problem for me, because the presence or absence of my usual row of extension icons and profile photo is enough of a clue. But I could see where someone who doesn't normally sign into Chrome, or who doesn't have very many extensions in their normal Chrome profile, could have trouble distinguishing it from their a profile. The windows will tend to look pretty similar.
  - cjcampbell 8y ago
    Exactly. If I need to run a browser in a special configuration, I want to take every precaution to avoid using it for anything but the intended purpose. Since I disable my profile and extensions, I get similar cues. The problem I see is that not everyone takes the same precautions. And plenty of developers accumulate these sort of tweaks and hacks in their daily driver without realizing or remembering that they've crippled their own security posture. From a UX perspective, my preference is to make it clear when normal security mechanisms are disabled.
kevin_thibedeau 8y ago
Why not just configure your server or a proxy to add the necessary headers that unlock CORS restrictions.
- reaperducer 8y ago
  Because in real companies the IT department needs a real good reason, or a large number of devs that need it, to reconfigure a server that way. If you're not a lone wolf, or working in the SV bubble, the IT and security departments are going to tell you to go pound sand.
  - AzMoo_ 8y ago
    Not really. In lots of relatively large companies there is a good relationship between infrastructure, development and security teams and they will work to find a solution that works for everybody.
    - vorticalbox 8y ago
      This is how it works at my work. CORS is allowed while running locally and then set while running in development and finally production.
  - sametmax 8y ago
    It's 2 lines of code with most modern web frameworks with junior level knowledge required. Actually, any people with decent dev skills (any people that receives money for code should...) add a conf switch for that since the begining of the project. I don't buy your comment at all.
- oelmekki 8y ago
  Because having code that behaves differently on development and production is never a solution, it's a workaround. Having bugs that can't be reproduced locally is the worst thing that can happen to a developer. So yeah, you can _just_ put environment settings if you have no other possible way, but you should really avoid it if there is any other one (like using chrome with CORS disabled, here).
giancarlostoro 8y ago
Not sure if it might have this but have you tried using Firefox Developer Edition? I would suggest if disabling CORS is missing to request it for Firefox Developer Edition. Its Firefox bleeding edge with some developer focused plugins out of the box.
vorticalbox 8y ago
You should be setting your server to set cors to allow all not disabling it in your browser. This is what we do while running docker for local development with node.
- oelmekki 8y ago
  At the very least, CORS should be disabled for localhost. I build interfaces using create-react-app, which launches a dev server on localhost:3000 (useful for things like live reload), making requests on a go api on localhost:5000. On production, both are on :80 and the backend serves frontend production files. This is annoying to alter the application code just to handle dev environment (although, this already happen in many other places, so it's not critical).
rendaw 8y ago
I set up a separate profile for debugging stuff - you may want to do this anyway since you'll be free to install development extensions willy nilly. Then you can change the theme for that profile which makes it obvious which instance you're using.
- cjcampbell 8y ago
  I do the same for myself, including an obnoxious theme. Not all developers are this cautious.
coffeeaddicted 8y ago
Chromium pops up some yellow bar with a warning when you use those flags. Isn't Chrome doing the same?
- cjcampbell 8y ago
  There's a temporary warning.

chipperyman573 8y ago

>My only wish is that Chrome would make it more obvious that it’s running with these protections disabled. I know this is beginning to become off-topic, but why? Presumably, if you're using a flag that has to be run from the command-line, you're either doing it on purpose or using hardware you don't own (and a keylogger is a much greater risk than anything else at that point)

Stratoscope 8y ago
I can't speak for OP, but for me the problem is that I likely already have normal Chrome windows open when I start a "special" Chrome instance with a private profile and other settings. So now when I see a Chrome window I would like to be sure whether it's my normal user profile or the special profile. In practice, it's not a problem for me, because the presence or absence of my usual row of extension icons and profile photo is enough of a clue. But I could see where someone who doesn't normally sign into Chrome, or who doesn't have very many extensions in their normal Chrome profile, could have trouble distinguishing it from their a profile. The windows will tend to look pretty similar.
- cjcampbell 8y ago
  Exactly. If I need to run a browser in a special configuration, I want to take every precaution to avoid using it for anything but the intended purpose. Since I disable my profile and extensions, I get similar cues. The problem I see is that not everyone takes the same precautions. And plenty of developers accumulate these sort of tweaks and hacks in their daily driver without realizing or remembering that they've crippled their own security posture. From a UX perspective, my preference is to make it clear when normal security mechanisms are disabled.

kevin_thibedeau 8y ago

Why not just configure your server or a proxy to add the necessary headers that unlock CORS restrictions.

reaperducer 8y ago
Because in real companies the IT department needs a real good reason, or a large number of devs that need it, to reconfigure a server that way. If you're not a lone wolf, or working in the SV bubble, the IT and security departments are going to tell you to go pound sand.
- AzMoo_ 8y ago
  Not really. In lots of relatively large companies there is a good relationship between infrastructure, development and security teams and they will work to find a solution that works for everybody.
  - vorticalbox 8y ago
    This is how it works at my work. CORS is allowed while running locally and then set while running in development and finally production.
- sametmax 8y ago
  It's 2 lines of code with most modern web frameworks with junior level knowledge required. Actually, any people with decent dev skills (any people that receives money for code should...) add a conf switch for that since the begining of the project. I don't buy your comment at all.
oelmekki 8y ago
Because having code that behaves differently on development and production is never a solution, it's a workaround. Having bugs that can't be reproduced locally is the worst thing that can happen to a developer. So yeah, you can _just_ put environment settings if you have no other possible way, but you should really avoid it if there is any other one (like using chrome with CORS disabled, here).

giancarlostoro 8y ago

Not sure if it might have this but have you tried using Firefox Developer Edition? I would suggest if disabling CORS is missing to request it for Firefox Developer Edition. Its Firefox bleeding edge with some developer focused plugins out of the box.

vorticalbox 8y ago

You should be setting your server to set cors to allow all not disabling it in your browser. This is what we do while running docker for local development with node.

oelmekki 8y ago
At the very least, CORS should be disabled for localhost. I build interfaces using create-react-app, which launches a dev server on localhost:3000 (useful for things like live reload), making requests on a go api on localhost:5000. On production, both are on :80 and the backend serves frontend production files. This is annoying to alter the application code just to handle dev environment (although, this already happen in many other places, so it's not critical).

rendaw 8y ago

I set up a separate profile for debugging stuff - you may want to do this anyway since you'll be free to install development extensions willy nilly. Then you can change the theme for that profile which makes it obvious which instance you're using.

cjcampbell 8y ago
I do the same for myself, including an obnoxious theme. Not all developers are this cautious.

coffeeaddicted 8y ago

Chromium pops up some yellow bar with a warning when you use those flags. Isn't Chrome doing the same?

cjcampbell 8y ago
There's a temporary warning.