Use more descriptive session mode names #738
Conversation
| // SessionModeAuthenticate is used when the session is for user authentication. | ||
| SessionModeAuthenticate = "auth" | ||
| // SessionModeChangePassword is used when the session is for changing the user password. | ||
| SessionModeChangePassword = "passwd" |
There was a problem hiding this comment.
I think at this point we should also rename this into "change-password", being the command line of the runner (and please also update pam/Hacking.md accordingly.
It may require regenerate some golden files I think... But that's a minor thing (do this change in a following commit, in case).
There was a problem hiding this comment.
I think at this point we should also rename this into "change-password"
I would love to do that, but this string is part of the API between authd and the broker, so it would be a breaking change.
There was a problem hiding this comment.
I think we can take the risk and have the brokers for now have a newName || "passwd", wdyt?
There was a problem hiding this comment.
Well, that's an option, but for what I meant, was the one in use by the runner... Adding an extra const in case.
There was a problem hiding this comment.
I think we can take the risk and have the brokers for now have a newName || "passwd", wdyt?
I don't see how we can do that. The session mode is passed from authd to the broker in the NewSession call. Current broker versions don't know about a "change-password" session mode, so they will break if they receive a call from authd which uses that.
What we could do is to keep using "passwd" in authd and start supporting both "change-password" and "passwd" in the next broker release. Then once all broker installations have been updated, we can start using "change-password" in authd in the following release.
There was a problem hiding this comment.
I'm not particularly in love on changing what's on the wire... Also because it would likely imply changes to gdm too, making the transition harder (we'd need to cross dependencies and so on...).
So, I wouldn't really change what's the string value or the proto ID for it, while using better naming anyways (you can still add another go file to the proto folder that does CHANGE_PASSWORD = PASSWD.
There was a problem hiding this comment.
Also because it would likely imply changes to gdm too
Oh, where are the session mode names being used in GDM?
There was a problem hiding this comment.
And is there currently no dependency between authd and gdm? What's the plan when we really need to make changes to the protocol?
There was a problem hiding this comment.
Oh, where are the session mode names being used in GDM?
Oh, no sorry... It's not used there I got confused by the layout modes...
Still, it doesn't change the fact that I'd prefer not to change the .proto file, if we want to be reliable (it's also an exercise for the future) we can add things but not change them in the run, until a new version is defined.
And is there currently no dependency between authd and gdm?
It can't be, because both can work without the other side. We only can suggest, but nothing else...
What's the plan when we really need to make changes to the protocol?
One thing we could do is making authd Breaks gnome-shell versions prior to X... However my idea when designing it, since the gdm protocol is also versioned, to change the version in case we need to and until we can support both versions.
There was a problem hiding this comment.
Still, it doesn't change the fact that I'd prefer not to change the .proto file, if we want to be reliable
I disagree regarding not changing proto definitions in general, because AFAICT a lot of those are only used by software which is packaged in the authd package (authd itself and the PAM and NSS modules), so in general it should be fine to make changes to those. Even if there is other software which uses the proto definitions, renaming a field shouldn't break compatibility (see https://stackoverflow.com/questions/45431685/protocol-buffer-does-changing-field-name-break-the-message).
In this specific case, we can't change the proto definition that easily, because we convert the protobuf object to JSON and pass it to the broker as well which unfortunately breaks the flexibility which the protobuf encoding provides. Didier and I agreed on a plan which should still allow us to rename those, by supporting both the old and the new name in new broker versions, and once all brokers have been updated (which we can see in the snap stats), we can change to the new name in authd. Do you see a problem with that?
One thing we could do is making authd Breaks gnome-shell versions prior to X
That seems like a good solution (I haven't given it much thought though).
However my idea when designing it, since the gdm protocol is also versioned, to change the version in case we need to and until we can support both versions.
We have the same issue with the authd <-> broker protocol, that we want to make small changes for which introducing a new API version would be overkill.
adombeck
force-pushed
the
more-descriptive-session-modes
branch
from
f213b36 to
caa3d4d
Compare
adombeck
force-pushed
the
more-descriptive-session-modes
branch
from
caa3d4d to
d42e0a2
Compare
* PASSWD -> CHANGE_PASSWORD: Session mode PASSWD is ambiguous, because authentication includes password authentication. CHANGE_PASSWORD should be clearer. * AUTH -> LOGIN: We also authenticate the user when the session mode is CHANGE_PASSWORD. LOGIN makes it clear that the session is for logging the user in.
adombeck
force-pushed
the
more-descriptive-session-modes
branch
from
d42e0a2 to
c6a2531
Compare
|
rebased on main and resolved conflicts |
|
@3v1n0 ping |
Session mode
PASSWDis ambiguous, because authentication includes password authentication.CHANGE_PASSWORDshould be clearer.This also changes session mode
AUTHtoAUTHENTICATEso that we use a verb (which describes the purpose of the session) for both session modes.