Allow vertical orientation for the userWidget so that the user-avatar
can be centered and user's name can be placed below it. The plan
for 3.36 is to use this vertical userWidget layout for both lock
and login screen.
The userWidget is also used while creating the user-selection list
at the login, hence we still need to keep the horizontal layout
for userWidget in place.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/922
Since the wiggle effect will be used by the redesigned prompt-dialogs
and we always want to use the same parameters, move those as defaults
for the wiggle function to the util.js file.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/942
Use the new StPasswordEntry for password entry fields
and remove all direct handling of clutter text of the entry
via clutter_text_set_password_char to show/hide the password
text. StPasswordEntry will provides a peek-password-icon which
will allow to show/hide the password present in the field to
the user in subsequent commits.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/619
Since ES5, trailing commas in arrays and object literals are valid.
We generally haven't used them so far, but they are actually a good
idea, as they make additions and removals in diffs much cleaner.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/805
ES6 allows to omit property names where they match the name of the
assigned variable, which makes code less redunant and thus cleaner.
We will soon enforce that in our eslint rules, so make sure we use
the shorthand wherever possible.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/805
Every since commit aa394754, StBoxLayout has supported ClutterActor's
expand/align properties in addition to the container-specific child
properties. Given that that's the only container left with a special
child meta, it's time to fully embrace the generic properties (and
eventually remove the child meta).
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/780
Remove the `this.actor = ...` and `this.actor._delegate = this` patterns in most
of classes, by inheriting all the actor container classes.
Uses interfaces when needed for making sure that multiple classes will implement
some required methods or to avoid redefining the same code multiple times.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/559
We now have everything in place to replace Tweener for all animatable
properties with implicit animations, which has the following benefits:
- they run entirely in C, while Tweener requires context switches
to JS each frame
- they are more reliable, as Tweener only detects when an animation
is overwritten with another Tween, while Clutter considers any
property change
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/22
The different units - seconds for Tweener and milliseconds for
timeouts - are not a big issue currently, as there is little
overlap. However this will change when we start using Clutter's
own animation framework (which uses milliseconds as well), in
particular where constants are shared between modules.
In order to prepare for the transition, define all animation times
as milliseconds and adjust them when passing them to Tweener.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/663
Braces are optional for single-line arrow functions, but there's a
subtle difference:
Without braces, the expression is implicitly used as return value; with
braces, the function returns nothing unless there's an explicit return.
We currently reflect that in our style by only omitting braces when the
function is expected to have a return value, but that's not very obvious,
not an important differentiation to make, and not easy to express in an
automatic rule.
So just omit braces consistently as mandated by gjs' coding style.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/608
While we have some style inconsistencies - mostly regarding split lines,
i.e. aligning to the first arguments vs. a four-space indent - there are
a couple of places where the spacing is simply wrong. Fix those.
Spotted by eslint.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/608
Certain keybindings should continue to work even when a popup
menu is on screen. For instance, the keybinding for showing
the app menu and the keyinding for showing the calendar are
examples.
This is achieved by putting in place a special "POPUP" action
mode, whenever a popup menu is active. This mode replaces
the (e.g., "NORMAL" or "OVERVIEW") action mode that was in place
for as long as the popup menu is active.
But those keybindings should not work when the user is at the
unlock dialog (which uses an action mode of "UNLOCK").
Unfortunately, since commit c79d24b6 they do.
This commit addresses the problem by forcing the action mode
to NONE at the unlock screen when popups are visible.
CVE-2019-3820
Closes https://gitlab.gnome.org/GNOME/gnome-shell/issues/851
ES6 finally adds standard class syntax to the language, so we can
replace our custom Lang.Class framework with the new syntax. Any
classes that inherit from GObject will need special treatment,
so limit the port to regular javascript classes for now.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/361
When we get a reset signal the preemptiveAnswer should be also unset or it will
be used next time the user authPrompt will be activated, even without any further
user interaction.
Fixes#311
When not using arrow notation with anonymous functions, we use Lang.bind()
to bind `this` to named callbacks. However since ES5, this functionality
is already provided by Function.prototype.bind() - in fact, Lang.bind()
itself uses it when no extra arguments are specified. Just use the built-in
function directly where possible, and use arrow notation in the few places
where we pass additional arguments.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/23
Any symbols (including class properties) that should be visible
outside the module it's defined in need to be defined as global.
For now gjs still allows the access for 'const', but get rid of
the warnings spill now by changing it.
https://bugzilla.gnome.org/show_bug.cgi?id=785084
Some PAM modules say "Press enter to continue" or
whatever. We need to support them.
This commit allows empty responses to PAM questions,
but still requires a non-empty response for username.
https://bugzilla.gnome.org/show_bug.cgi?id=784360
When the user gets long failure messages from pam, the authPrompt
message label will clip the message and ellipsize with '…'.
This commit turns off ellipsization from the label, so it will
properly wrap.
https://bugzilla.gnome.org/show_bug.cgi?id=764445
The Next and Sign In buttons are disabled when the username/password
field is empty. However, the user can still bypass this button by
pressing the enter key, leading to some odd glitches with the log in
for 'Not Listed?' users.
This is easy to fix by simply not progressing to the next screen when
the button is disabled.
https://bugzilla.gnome.org/show_bug.cgi?id=746180
When the user successfully types their password, we should hide
the spinner from the button well right away, so it doesn't
consume resources until reset (which may happen significantly later
if the user is vt switched away)
https://bugzilla.gnome.org/show_bug.cgi?id=753891
The code previously tried to stop spinner after it was hidden, but
due to an incorrect check was only stoppig it after it was shown.
Also, it was only stopping after hiding due to an animation, and
failing to stop it in the non-animated case.
This left the spinner hidden and running while VT switched away
from the login screen, only stopping when the auth prompt was
reset when switching back.
https://bugzilla.gnome.org/show_bug.cgi?id=753891
We only need the user verifier for the purpose of user verification.
Once it's complete we should clear it so it doesn't get in the way
later.
This fixes a bug introduced in commit 3c8c5a5570 that leads to the
user session crashing when the login screen is reactivated.
https://bugzilla.gnome.org/show_bug.cgi?id=753181
The user should be allowed to cancel if verification hasn't
started yet and they're typing in their username. This
commit changes the authPrompt cancel function to not
ignore such requests.
https://bugzilla.gnome.org/show_bug.cgi?id=752739
Normally the user isn't allowed to proceed passed
the username question until they've filled it in.
To ensure this, the authprompt code desensitizes
the next button when the number of characters change to
zero.
Unfortunately it fails to desensitize the next button
up front when the entry starts out empty.
This commit addresses that bug.
https://bugzilla.gnome.org/show_bug.cgi?id=752739
If the next button ever gets set to Sign In, it won't
get reset to next until the next question asked by pam.
This commit ensures it gets reset to Next when asking
for the username.
https://bugzilla.gnome.org/show_bug.cgi?id=752739
We currently only cancel the user verifier on reset if
verifying, but that means we don't properly cancel it when
asking for a username at the Not Listed screen.
The object already handles getting called when there is
nothing to cancel, so just cancel it unconditionally.
https://bugzilla.gnome.org/show_bug.cgi?id=752438
It's possible for a user to type their password so quickly
that GDM hasn't even had time to ask for the password yet,
much less have time to process the answer.
In that situation, we tuck the user response away as
_preemptiveAnswer, and pass it along to GDM when GDM is finally
ready for it.
The problem is, there's a bug in the code, where we send
null for the service name in the answer, instead of the right
service name (say "gdm-password").
This commit addresses the bug by making sure we don't pass the
answer along, until the service name is properly set in
_queryingService. To ensure that, answering query (answerQuery)
based on _preemptiveAnswer has been shifted right below
this._queryingService = serviceName;
https://bugzilla.gnome.org/show_bug.cgi?id=737586
Once verification has succeeded, the train's already
left the building and we shouldn't allow canceling.
This commit renders the cancel button non-reactive
and makes the cancel function be a noop after
verification succeeds.
https://bugzilla.gnome.org/show_bug.cgi?id=740141
The smartcard service is put in the foreground in two cases:
1) If password service is disabled by admin configuratoin
2) if a smartcard is inserted
In either case we don't want to ask the user to pick a user from the
userlist. We currently only avoid asking in case 2.
This commit fixes case 1.
https://bugzilla.gnome.org/show_bug.cgi?id=726263
When set to fill, the label will always end up left-aligned, which
is only correct in LTR locales. Set the alignment explicitly to
work in both RTL and LTR locales.
https://bugzilla.gnome.org/show_bug.cgi?id=712638
After a user types in their password at the login screen, one
of two things can happen
1) a new session is started
2) an existing session is switched to
In the latter case, GDM sends a reset signal to the login screen,
so it knows to go back to the user list and wait to be summoned
again.
Unfortunately, all reset signals are ignored after verification
success. The reason is because the reset handler was copied from
the unlock dialog as part of a deduplication effort in commit
7e7295f259 and the unlock dialog
handler at the time also emitted a "failed" signal on reset
(which wouldn't make sense to emit after success).
These days "failed" is handled in a different way.
This commit changes the code to let reset signals through after
successful verification.
https://bugzilla.gnome.org/show_bug.cgi?id=710456
oVirt is software for managing medium-to-large scale deployments of
virtual machine guests across multiple hosts. It supports a feature
where users can authenticate with a central server and get
transparently connected to a guest system and then automatically get logged
into that guest to an associated user session.
Guests using old versions of GDM support this single-sign-on capability
by means of a greeter plugin, using the old greeter's extension
API.
This commit adds similar support to the gnome-shell based login screen.
How it works:
* The OVirtCredentialsManager singleton listens for
'org.ovirt.vdsm.Credentials.UserAuthenticated'
D-Bus signal on the system bus from the
'org.ovirt.vdsm.Credentials'
bus name. The service that provides that bus name is called
the oVirt guest agent. It is also responsible for interacting
with the the central server to get user credentials.
* This UserAuthenticated signal passes, as a parameter, the a token
which needs to be passed through to the PAM service that is specifically
set up to integrate with the oVirt authentication architecture.
The singleton object keeps the token internally so it can be queried
later on.
* The OVirtCredentialsManager emits a signal 'user-authenticated' on
it's object once the dbus signal is triggered
* When the 'user-authenticated' signal is emitted, the login screen
tells GDM to start user verification using the PAM service. The
authentication stack of the service includes a PAM module
provided by oVirt that securely retrieves user credentials
from the oVirt guest agent. The PAM module then forwards those
credentials on to other modules in the stack so, e.g.,
the user's gnome keyring can be automatically unlocked.
* In case of the screen shield being visible, it also will react on that
'user-authenticated' signal and lift the shield.
In that case the login screen will check on construction time if
the signal has already been triggered, and a token is available.
If a token is available it will immediately trigger the functionality
as described above.
Signed-off-by: Vinzenz Feenstra <evilissimo@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=702162
A conversation is finished after failing, and we are expecting a new
one to be started shortly after. However if we encounter an existing
reference to a previously set _queryingService, we will clear the
password entry, which might already contain a partially typed password
at that point. The behavior does make sense in the case of conflicting
conversations, but in the failure case it is both unexpected and
annoying, so clear _queryingService early to prevent this.
https://bugzilla.gnome.org/show_bug.cgi?id=708186
This commit consolidates the styles of the various
message types into one 'login-dialog-message' style
and then adds additional styles on top to cover the
differences.
This allows us to give the message label an initial
style so that is padded properly before any messages
are displayed.
https://bugzilla.gnome.org/show_bug.cgi?id=706670
This commit detects when a user inserts a smartcard,
and then initiates user verification using the gdm-smartcard
PAM service.
Likewise, if a user removes their smartcard, password verification
(or the user list depending on auth mode and configuration) are initiated
https://bugzilla.gnome.org/show_bug.cgi?id=683437
Some pam modules prompt without expecting the user to type
an answer back (e.g. "Please swipe finger"). We need to
emit prompted in this case too, so the the dialog will get shown.
https://bugzilla.gnome.org/show_bug.cgi?id=683437
This commit introduces a new BeginRequestType enum which gets
passed to the 'reset' signal to specify whether
a username should be provided to the begin() method and changes
the loginDialog to comply.
Currently, the signal only ever gets emitted with
AuthPrompt.BeginRequestType.PROVIDE_USERNAME
but that will change in the future when providing smartcard
support.
https://bugzilla.gnome.org/show_bug.cgi?id=683437
We currently emit "failed" any time the UserVerifier is reset,
and user verification didn't succeed prior.
A more conceptually clear time to emit "failed" would be if
the UserVerifier is reset and user verification failed prior,
and to emit "failed" if the user cancels unlock.
This commit restructures things to do that. Aside from being
more conceptually clear, it also lays the groundwork for us
to be able to reset the unlock screen without failing.
https://bugzilla.gnome.org/show_bug.cgi?id=683437
authPrompt.reset() currently only leaves the authPrompt in a
sane state if the user isn't verifying.
This commit makes sure to cancel verification if a reset happens
while verification is in process.
https://bugzilla.gnome.org/show_bug.cgi?id=683437
onAskQuestion has this code:
if (this.verifyingUser)
this.cancelButton.show();
else
this.cancelButton.hide();
but onAskQuestion can only be called when this.verifyingUser is true.
Also, cancelButton is public, and it only ever otherwise gets hidden
from callers.
This commit drops mucking with cancelButton visibility, leaving it
entirely up to the callers to deal with.
https://bugzilla.gnome.org/show_bug.cgi?id=683437
If the first question asked to a user is from the
shell and not from the PAM service (i.e. Username: ),
then we'll save what the user types until PAM asks
a question and then try to send it to PAM.
This commit makes sure the preemptive answer can be used
before the PAM conversation gets started, and makes sure
to discard the preemptive answer if we're not expecting it.
https://bugzilla.gnome.org/show_bug.cgi?id=705370
Right now we have two booleans that specify when user verification
is happening and when it succeeded, respectively.
This commit consolidates them into one AuthPromptStatus enumeration.
This clean up will allow us to check for verification failure more
easily.
https://bugzilla.gnome.org/show_bug.cgi?id=683437
Right now the whole authPrompt spreads out if a PAM message
comes in that longer than the entry.
This commit changes it to wrap instead, by forcing the
auth prompt to be a fixed width (slightly bigger than
the entry width was sized to previously).
https://bugzilla.gnome.org/show_bug.cgi?id=705037
When a ShellUserVerifier is asked to verify a user at the login
screen it will transparently first try to reauthenticate the user
against an existing session and then fall back to logging a user
into a new session. The former is used for user switching.
It's useful to know which type of verification is happening, so
the next button can be made to say "Unlock" instead of "Sign In" when
a user is already signed in.
This commit exports a new "reauthenticating" property on the
ShellUserVerifier that the auth prompt checks when deciding which
label to use for its next button.
https://bugzilla.gnome.org/show_bug.cgi?id=704795
If there are no messages in the queue and a user starts to
type then we can safely hide the message label since the
user has probably already read it.
This fixes a weirdness where "Incorrect Password" messages stay
around, even as the user types in the new correct password.
https://bugzilla.gnome.org/show_bug.cgi?id=704817
There's quite a bit of duplicated code between the login dialog
and the unlock dialog dealing with the various signals from the
ShellUserVerifier.
This commit moves that duplicated code into the AuthPrompt.
https://bugzilla.gnome.org/show_bug.cgi?id=704707
