You would define multiple changeset functions in that case. In general, in ecto, almost no configuration or validation is “global”. There is nothing special in the function called changeset/2.
I’m sorry, but I really don’t see a problem this is trying to solve. It’s, of course, different if you don’t use ecto, but if you do, I can’t see an advantage this offers.
I’m sorry if I came through being hostile (and reading my answers I could see this being the case). This was not my intention, I’m just trying to understand if there is some gap in how ecto works and if so, how we could fix it.
No worries - I appreciate the input. This is just something I’m trying out right now, so I don’t even know if it works well.
So the multiple changeset option in this example would be something like:
def update_changeset(model, params) do
model
|> cast(params, @public_fields)
|> validate_common
end
def reset_password_changeset(model, params) do
model
|> cast(params, [:password_reset_code, :password_reset_sent_at])
|> validate_common
end
If that is the case I would probably prefer that. An advantage of the plug approach would be to avoid the extensive refactoring I probably have to do to get to the point where I can take advantage of these custom changesets.
I think the multiple changeset option is ideal. Though, I do get the impulse for a Plug! Having the whitelisted parameters declared right in the controller can make it easier to reason about what data you’re actually passing around, similar to Rails’ strong params. That’s why I like the explicit parameter passing approach (combined with multiple changesets), though it can get a bit unwieldy with lots of values.
I think the multiple changeset option is ideal.
+1, I also like this approach. To avoid duplication I often have a base_changeset for stuff that every generic change can do that is used (in case of User schema) by admin_changeset, form_registration_changeset, edit_self_changeset etc.
Works pretty well for me, never had any problems.
I keep coming back on the session cookie issue. Wouldn’t it be quite simple to just generate a random key for each user on creation and putting that one into the session alongside the user id. Then in the authentication plug simply search the db for the user by the key and the id. In case a cookie is compromised one could update that users key without effecting other users.
I think the ideal solution is pretty close to that, which is to generate a unique, secure-random session_id for the user. Then, on every login/logout you update the value. The auth plug would function like you say, where it will fetch the user by the secure token (basically how people do it now, except with a session_id instead of user_id).
In the event of a compromised cookie, all a user needs to do is log out!
Probably only on logout, because otherwise logins would invalidate prev. sessions as well.
You are right, my answer assumes a single session. For multiple active sessions, you’d definitely want to architect things differently.