The mockups do not mention the "Password:" above the password
entry. Although preserve the label place-holder for question
prompt other than PASSWORD_SERVICE_NAME.
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
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
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
We are currently inconsistent with whether or not to put a space
after catch clauses. While the predominant style is to omit it,
that's inconsistent with the style we use for any other statement.
There's not really a good reason to stick with it, so switch to
the style gjs/eslint default to.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/607
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 in lockscreen mode there's no point of resetting the auth login as there's
no welcome screen, and that would just cause the UI to freeze, with no reason.
This could have been useful if we were stopping the user to login for a given
time after ALLOWED_FAILURES attempts, but this is not the case yet.
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
While we've always considered it good style to initialize JS properties,
some code that relies on uninitialized properties having an implicit
value of 'undefined' has slipped in over time. The updated SpiderMonkey
version used by gjs now warns when accessing those properties, so we
should make sure that they are properly initialized to avoid log spam,
even though all warnings addressed here occur in conditionals that
produce the correct result with 'undefined'.
https://bugzilla.gnome.org/show_bug.cgi?id=781471
If the user fails to enter their password then hits escape, we
jump back to the user list, then ask again for a password in a
garbled screen. this commit fixes that by skipping a retry if
the operation is cancelled.
https://bugzilla.gnome.org/show_bug.cgi?id=784361
If the user fails to enter their password then hits escape, we
jump back to the user list, then ask again for a password in a
garbled screen. this commit fixes that by guarding against the retry
if the fail counter is reset.
We rely on the service to detect whether a fingerprint reader is
present. It is fine to not support fingerprint authentication
when the service is missing, but currently we don't handle this
case at all and end up with a non-functional login screen.
https://bugzilla.gnome.org/show_bug.cgi?id=780063
User read time per character has been changed from 16ms to 48ms because the
message of information about last login is displayed for half a sec that is not
a good user experience. So time to read a character is increased to 48ms from 16ms.
https://bugzilla.gnome.org/show_bug.cgi?id=720885
If a smartcard is missing from the reader when we start up,
and the system is configured to disable password authentication,
then we need to ask the user to insert their smartcard.
This commit fixes that.
https://bugzilla.gnome.org/show_bug.cgi?id=740143
Incorrect braces meant that if the ShellUserVerifier was destroyed before
the call to fprintManager.GetDefaultDeviceRemote(), the reply would result in
an error.
https://bugzilla.gnome.org/show_bug.cgi?id=738256
We only want to react to the card the user logged in with, at
the unlock screen. We check "at the unlock screen" by checking
the "reauthenticating" state variable. That variable is the
wrong one, though. It gets set too late, and in some cases, gets
set at the login screen, too. We should be checking this._reauthOnly
instead.
This commit fixes that.
https://bugzilla.gnome.org/show_bug.cgi?id=726262
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
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
The duplication makes the function look a lot more complicated
than it actually is.
This commit moves the common code to a new _startService function.
https://bugzilla.gnome.org/show_bug.cgi?id=683437
Currently, fingerprint authentication is always a secondary thing.
If a user wants to swipe their finger when the computer is asking
for a password, so be it.
This commit paves the way for making fingerprint auth optionally
be the main way to authenticate. Currently there's no way to enable
this, but in a future commit will honor
enable-password-authentication=false
in gsettings.
https://bugzilla.gnome.org/show_bug.cgi?id=683437
Right now, the primary way a user logs in is with
a password. They can also swipe their finger, if their
fingerprint is enrolled, but it's expected the fingerprint
auth service won't ask questions the user has to respond to
by typing. As such, we ignore questions that comes from
anything but the main auth service: gdm-password.
In the future, if a user inserts a smartcard, we'll want
to treat the gdm-smartcard service as the main auth service,
and let any questions from it get to the user.
This commit tries to prepare for that eventuality by storing
the name of the default auth service away in a _defaultService variable
before verification has begun, and then later checking incoming
queries against that service instead of checking against
string 'gdm-password' directly.
Of course, right now, _defaultService is always gdm-password.
https://bugzilla.gnome.org/show_bug.cgi?id=683437
