Comments (10)
Could this be due to the phoenix plug compilation, by any chance? https://hexdocs.pm/plug/Plug.Builder.html#module-options the init_mode: :compile
It happened to me before outside Ueberatuh
, but still, just checking the boxes.
from ueberauth.
It's configurable, yes, but having the return value for init/1
compiled into any module plug is the default for production use and not a bug.
from ueberauth.
I am not sure what you mean precisely.
I do remember that if some plugs want to read things from the environments and rely on runtime.ex
then they will need to move the look up to the call/2
callback
from ueberauth.
Whats the status on this one?
from ueberauth.
So I guess the issue would come down to the fact that Providers are initialized during compilation time?
from ueberauth.
After talking with @LostKobrakai on Slack we determined that this boils down to not being able to set any option at runtime due to Plugs being pre-initialized. Thus this makes this related to #170
from ueberauth.
My general take, it is frustrating that such behavior is controlled by Plug
at the app-level.
The primary question here is, what Plug
want people to use init/1
callback for?
We use init
to setup up the options. But isn't until a given environment with a given flag come across that we discover that init
isn't being called per se at runtime.
🤷🏻 🤷🏻 🤷🏻 🤷🏻 No clue, I think it is worth to bring the conversation to Plug
and define some anti-patterns for the community, this is not the first time that it happens to me personally.
I would say, move things to the call/2
callback for now.
from ueberauth.
Note that init/1 may be called during compilation and as such it must not return pids, ports or values that are specific to the runtime.
Plug init/1
has been documented to likely be executed at compile time since the first version existing on hexdocs. This is very much part of the expectation of how plugs are to be implemented.
The primary question here is, what Plug want people to use init/1 callback for?
It is there to validate and possibly restructure the plug opts passed as input to init/1. Those opts commonly come from the second parameter of the plug/2
macro, where they're also compile time known.
The issue here is that Ueberauth
also uses that callback to do the side effect of looking into the application environment.
from ueberauth.
So the technical problem here is that the code we want needs to be executed only once, lazily before first call. Ideally we would like to not have to compute this value every time plug is called. The computation should be very light and only passing but maybe shoving this into ets for cache would be an option?
There is also an option to move this computation to the runtime.exs file, but that smells like an antipattern. Another option would be to maybe add that into the startup_phase, so its precomputed and then stored in something like ETS or dynamically loaded modules. But that also smells.
Maybe first iteration to call the init in the call as previous mentioned? Is there a possibility of this breaking existing code? Should there be an explicit switch to enable this in new iterations of the providers?
from ueberauth.
@Hajto keep it simple, like Joe said: make it work, make it beautiful and if you really really need to, make it fast.
Moving the opts to call/2
should fix the issue.
from ueberauth.
Related Issues (20)
- OAuth2 needs new maintainers HOT 4
- State nonce cookie should properly be signed HOT 2
- How can run Ueberauth plug directly? HOT 3
- Custom `callback_port` and `callback_scheme` not used HOT 1
- Callback URL not mounted right when router has nested paths
- Can't set strategy options at runtime HOT 2
- Line Login v2.1 update request which I've done HOT 4
- Gracefully handle unknown providers HOT 10
- App.Auth.AuthController.request/2 is undefined or private HOT 1
- minor: mix package versions are out of date
- New hex.pm release? HOT 1
- Incorrect callback_url when using Bandit.PhoenixAdapter
- put_session successful, but get_session failed HOT 1
- function MyAppWeb.OAuthController.request/2 is undefined or private HOT 1
- Support for nonces HOT 1
- FR: Support multiple usages of the same strategy in config HOT 13
- Incomplete docs to configure pipeline and check that user is authenticated HOT 3
- Latest release breaks existing paths HOT 6
- Latest version is retired HOT 7
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 ueberauth.