-
-
Notifications
You must be signed in to change notification settings - Fork 860
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
# inside double quotes still treated as inline comment #601
Comments
Thank you for raising this. We are looking into it. Anyone else this is happening to, please +1. |
@Devtronyx interesting. In this case, even though it's a json this is read as a string. You'd have to quote the entire value in order to properly parse this (in your case since you already use the double quotes I suggest to use the single ones as wrapper): SOME_KEY='{"field1":"some value", "field2": "does not stop here#this is not discarded"}' |
Broke us too. I don't know though what's more "correct" behavior - to require a space before |
Quick collection of patterns I noticed in other tools since yesterday: vscode: syntax highlighting suggests: unquoted Github: seems to look for space character FOO=bar#baz
FOO=bar #baz
FOO="bar#baz"
FOO="bar #baz"
FOO='bar#baz'
FOO='bar #baz' python-dotenv started out where we are but with version 0.10.3 they introduced a check for space character unix (GNU coreutils) env I've already shared here: #568 (comment) @kirillgroshkov you wrote "Broke us too". Did you mean that you were also using unquoted json in your .env and it broke and you were expecting it not to break, or in general that you had to adapt your .env because of the recent change because you had an unquoted string with I'm wondering if perhaps I should have mentioned the change also here: https://github.com/motdotla/dotenv#what-rules-does-the-parsing-engine-follow 🤔 |
Just ran into this. It's very common for generated secrets to include VAR_WITH_SPECIAL_CHARS=space slash/other@#1!= But unfortunately: --- Expected
+++ Received
{
- VAR_WITH_SPECIAL_CHARS: "space slash/other@#1!="
+ VAR_WITH_SPECIAL_CHARS: "space slash/other@"
} |
@mrliptontea yes, it is very common. We are working on the long term solution for this. Until then, you can do:
P.S. If option 1 is a hassle because you have a large team that would all need to update their |
@mrliptontea even Github highlights the @motdotla given that the change seems to have broken things for so many, I've created a new PR: #603 |
Thank you @jonathan-reisdorf. Patch is in |
So patch is in That said..
So our recommendation is to start quoting any values containing PR is here #608 and will likely go out as a release tomorrow or the next day. |
@motdotla According to OWASP a password can contain any of the following characters https://owasp.org/www-community/password-special-characters. How do you suggest storing passwords, in a way that dotenv can correctly parse them? |
v14.2.0
SOME_KEY={"field1":"some value", "field2": "stops here#this is discarded"}
When above line is parsed generates the following output
SOME_KEY: {"field1":"some value", "field2": "stops here
which in turns gives a SyntaxError: Unexpected end of JSON input
The text was updated successfully, but these errors were encountered: