Comments (15)
@scrogson after discussing this with @yordis on Slack, this doesn't sound like a bad idea so long as we provide a sane default. In his case they'd like to load their third-party credentials from a database and not config/*.exs
or system env.
from ueberauth.
@rmoorman the first step IMHO is to remove the dependency with Plug.Conn
from the Core (we add the HTTP dependency on top of the Core) This will allow us to deal with function calls without any Plug.Conn
involve so it is much easier.
Multi-tenant at that moment becomes easier because for the Core still the same but you can create your own Controller/Plug/Middleware that knows how to read the configuration either by using URLs or Headers or whatever decision you made.
But I think that we should tackle the Plug.Conn
first and then move to this one, because it becomes much easier, maybe we do not need to configure anything per module because it is easier to write some Controller that initialize the workflow
Thinking out loud
from ueberauth.
@yordis sorry, I'm not following the use-case you've outlined. Could you expand on it?
from ueberauth.
@scrogson Right now we have to put, for example client_id
and client_secret
, the configurations in the config.exs
so it's hard coded using the language.
The idea is that you could have different ways to load the configuration for the strategies. I could use Ecto
(meaning database more than actually Ecto) for load the configuration data from a database.
This allow us to even have multiple configurations for the strategies if we want to actually base the configuration per plug
config.
from ueberauth.
When we're talking about credentials, are we talking about ueberauth or particular strategies? The solution will likely be different
from ueberauth.
@hassox the idea is to be able to configure the strategies from the database.
For example: Facebook strategy, needs client_id
, client_secret
, default_scope
, display
, profile_fields
; which it can be configure from some database or any module that you want to implement.
Of course, we need to agree in some interface for the module, but that's the idea
from ueberauth.
Is there any progress on this? If not, I might work on this, as we need this in the near future.
from ueberauth.
@arjan do you have any thing in mind on how to start with this?
@scrogson and I talked about it but we didn't settle on anything.
There is some thoughts around this like:
Configuration based on some parameter: this parameter could come from some HTTP request or you calling directly the Ueberauth workflow with some key I am guessing. We need to think about it.
from ueberauth.
So, basically we would like all configuration related to a strategy to be dynamically retrieved, right?
Maybe we can create a config setting:
config :ueberauth, Ueberauth, strategy_reader: {ReaderModule, :read_config, []}
Which specifies a MFA tuple for the reader function. The strategy reader would be called every time a strategy configuration needs to be retrieved (using Kernel.apply/3
, with as argument the strategy module, the %Plug.Conn{}
of the current request, plus the extra "static" arguments given in the MFA tuple)
The default implementation would be something like:
defmodule ReaderModule do
def read_config(strategy_mod, _conn), do: Application.fetch_env!(:ueberauth, strategy_mod)
end
Where strategy_mod
is something like Ueberauth.Strategy.Facebook.OAuth
.
Based on the conn
, it is possible to fetch different configuration variations, for example by using the conn.host
header. Or by retrieving something from the session.
from ueberauth.
@arjan yes and no,
That could be a possibility but we are trying to move away from Plug.Conn
as a direct requirement, in my case, I use GraphQL API with Absinthe so I don't have access to Plug.Conn
or in the other hand my architecture do not depends of Plug.Conn
so we need to find a way to remove.
Also, related to that, I would pass some parameter that helps the reader to know which strategy is because.
What if you have multiple strategies fro Facebook? How do you know which one you refer to if you don't pass an extra information?
from ueberauth.
Agreed. Did not know about the moving away from Plug part (I saw it listed in the dependencies that's why
my proposal). Anyhow, of course you can always (mis)use the process dictionary for this... e.g. an Absinthe middleware putting some identifier in, and the strategy reader function using that info.
Absinthe itself uses the pdict also quite heavily btw ;-)
Alternatively we can create some initialization function which you need to call on each request before the ueberauth magic happens. It returns some {:ok, value}
tuple and this value is passed in to the reader function by Ueberauth. This init function then needs to be called from a Plug or Absinthe middleware.
from ueberauth.
Also keep in mind that (based on e.g. request information) one request would only be allowed to use a Facebook strategy while another one could use microsoft and fitbit. I don't know if that kind of flexibility is planned to be built in (or at least planned to be achievable through extension; it has been suggested though within #61) but it would be pretty great to have it for multi-tenant scenarios.
from ueberauth.
Makes sense @yordis , thank you!
from ueberauth.
Okay, so I hear it's not time for me to start on this, I guess :-) Is there already an issue for the Plug.Conn rewrite that I could track?
from ueberauth.
Moved to #90
from ueberauth.
Related Issues (20)
- nil given for :email. Comparison with nil is forbidden as it is unsafe. Instead write a query with is_nil/1, for example: is_nil(s.email) HOT 1
- 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
- callback_port config compiled into plug at compile time 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
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.