Comments (12)
Hi @geofflane. Thanks for the bug report. As I read the code, if you omit the secret_key from your config at compile time, Guardian should correctly fetch it from the env at runtime. The compile time envs should only be used at compile time by the macro. With the change to use compile_env elixir now tools like Mix will store the values used during compilation and compare the compilation values with the runtime values whenever your system starts, raising an error in case they differ.
This properly why you get an error.
Would mind trying to not set the secret key at compile time and only at runtime.
from guardian.
# config/config.exs
config :photon, PhotonPerm.Guardian,
issuer: "PFF.Photon"
with
# config/runtime.exs
config :photon, PhotonPerm.Guardian,
ttl: {14, :days},
secret_key: System.fetch_env!("SECRET_KEY_BASE")
Has the same issue:
* Compile time value was set to: [issuer: "PFF.Photon"]
* Runtime value was set to: [issuer: "PFF.Photon", ttl: {14, :days}, secret_key: "xxx"]
from guardian.
This is impacting us as well and I don't think the changes that were made are actually intended...
Just spelunking in the code a bit here:
https://github.com/ueberauth/guardian/blob/master/lib/guardian.ex#L343
# Provide a way to get at the configuration during compile time
# for other macros that may want to use them
@config fn ->
the_otp_app |> Application.compile_env(__MODULE__, []) |> Keyword.merge(the_opts)
end
@config_with_key fn key ->
@config.() |> Keyword.get(key) |> Guardian.Config.resolve_value()
end
@config_with_key_and_default fn key, default ->
@config.() |> Keyword.get(key, default) |> Guardian.Config.resolve_value()
end
^^^ I don't see anywhere that this is used.
And the problem is actually this code itself I think. It's not obvious to me what this is being used for but I think it's the issue.
@doomspork can you comment on where @config
is used?
I think the way to resolve this is to just delete that code. I think that Elixir releases means that it no longer behaves the way it was intended 5 years ago when it was written.
(but I could totally be wrong because it's not clear to me what uses it.)
from guardian.
Digging a bit deeper it looks like permissions uses @config_with_key
. But I think it can be refactored so that it uses a function. @config_with_key_and_default
isn't used.
If permissions really needs this at compile time maybe we could compile_env for just that one key?
from guardian.
# config/config.exs config :photon, PhotonPerm.Guardian, issuer: "PFF.Photon"
with
# config/runtime.exs config :photon, PhotonPerm.Guardian, ttl: {14, :days}, secret_key: System.fetch_env!("SECRET_KEY_BASE")
Has the same issue:
* Compile time value was set to: [issuer: "PFF.Photon"] * Runtime value was set to: [issuer: "PFF.Photon", ttl: {14, :days}, secret_key: "xxx"]
Yea okay, this seems to not be intended. As @idyll writes looks like this compile time env vars are specific to the permission, the only concern I have is if some library users use this as well. I guess we can fix this up and cut a major release just to be sure?
from guardian.
I think we should be able to the compile_only only for the permission key of the environment, and then consider that to be the only compile time var atm.
from guardian.
That's my expectation. That should fix it.
from guardian.
Would any of you @idyll @geofflane be interested in fixing this or maybe @yordis. I have quite a busy schedule lately so I wont have time to look at this atm.
from guardian.
Something told me that the fix wouldn't work. I asked Jose about it, and he said it was safe to merge. My apologies.
This week I am in the middle of deploying a brand new system, so I don't have time, but I am more than happy to help with some code review.
If you want to take the lead, please do. Otherwise, let me see if I find some time for it.
from guardian.
I probably can look in a day. If someone gets to it before me, let me know.
from guardian.
# config/config.exs config :photon, PhotonPerm.Guardian, issuer: "PFF.Photon"
with
# config/runtime.exs config :photon, PhotonPerm.Guardian, ttl: {14, :days}, secret_key: System.fetch_env!("SECRET_KEY_BASE")
Has the same issue:
* Compile time value was set to: [issuer: "PFF.Photon"] * Runtime value was set to: [issuer: "PFF.Photon", ttl: {14, :days}, secret_key: "xxx"]
Any update here? Running into the same issue on our application with this exact same configuration
from guardian.
Took a stab at a PR for this. It's runtime behaviour so it's a bit hard to write tests around. Any help there would be appreciated.
from guardian.
Related Issues (20)
- Compilation error in file guardian.ex: type options/0 undefined HOT 1
- Is guardian relying on JWT's fixed side ? HOT 2
- Provide a way to retrieve verifying secret at runtime using connection information
- Help with EnsureNotAuthenticated HOT 1
- Successfully validates a JWT token with a timestamp in the past
- use Bitwise is deprecated in elixir 1.14-dev
- Warning causing compile error with Elixir 1.14.0 HOT 1
- changelog is missing in the doc HOT 1
- all_permissions? function returns true even if permission set given is not within the list of permissions provided and compiled
- I would like to be able to set permissions from a DB table rather than hard coded in a permissions set. HOT 8
- guardian.encode_and_sign 1st argument: not an atom HOT 1
- Opaque errors when token verification fails HOT 3
- Using an environment variable as a secret key in elixir 1.14 HOT 2
- Breaking Change on 2.3.1 - Can't encode Bitwise Permissions HOT 6
- Generating a JWT with kty=oct can fail because of incorrect Base64 encoding
- after_encode_and_sign result not used HOT 2
- Move to Elixir 1.14 and otp 25 HOT 3
- system_time vs os_time and time drift HOT 1
- refresh_from_cookie only accepts "default" as key HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from guardian.