login: Warn before logging into multiple hosts #20861
Conversation
mvollmer
force-pushed
the
login-warn-multihost
branch
from
d5b6ca1 to
3462e54
Compare
|
Old demo: https://youtu.be/lvR2youiY4M |
| .login-pf #banner { | ||
| .login-pf #banner, .login-pf #multihost-warning { | ||
| margin-block: 1rem 0.5rem; | ||
| margin-inline: 0; | ||
| grid-area: banner; | ||
| inline-size: 100%; | ||
| } | ||
|
|
||
| #banner-message { | ||
| #banner-message, #multihost-message { |
There was a problem hiding this comment.
We really shouldn't target IDs in the CSS. We already do, I know, but we shouldn't add more. (The selectors should be targeting classes.)
We especially should not have IDs nested under other selectors like this.
Ideally, we'd fix the older parts by changing those too.
Anyway, I'm not expecting you to have to fix this, just pointing out that it's bad form. We're already doing bad stuff anyway in the file, so it's not a huge deal. But it's important for new code and we should (at some point) clean up instances where IDs are used in CSS. It's important everyone on the team understands this, as using IDs leads to other bad things, like CSS not working as expected, resulting in !important and other bad things.
The ID selector has high specificity. This means styles applied based on matching an ID selector will overrule styles applied based on other selector, including class and type selectors. Because an ID can only occur once on a page and because of the high specificity of ID selectors, it is preferable to add a class to an element instead of an ID. If using the ID is the only way to target the element — perhaps because you do not have access to the markup and cannot edit it — consider using the ID within an attribute selector, such as p[id="header"]. Learn specificity.
(Note: We shouldn't use an attribute selector as it suggests, but actually fix the HTML.)
IDs are great and to be used in JavaScript for quick specific element selecting (as there's only one unique instance of an ID allowed on a document), of course. But it's bad for CSS.
There was a problem hiding this comment.
(BTW: I'm not blocking on this in this PR or nitpicking, just pointing out something that would have really bad side effects, especially elsewhere in Cockpit.)
Adjust to cockpit-project/cockpit#20861 to keep tests uniform across OSes. Fixes cockpit-project#1913
Adjust to cockpit-project/cockpit#20861 to keep tests uniform across OSes. Fixes #1913
mvollmer
force-pushed
the
login-warn-multihost
branch
from
3462e54 to
7dd084c
Compare
mvollmer
force-pushed
the
login-warn-multihost
branch
from
7dd084c to
50b915c
Compare
| redirect_to_current_machine(); | ||
| else { | ||
| id("multihost-message").textContent = format(_("You are already connected to '$0' in this browser session. Connecting to other hosts will allow them to execute arbitrary code on each other. Please be careful."), | ||
| cur_machine == "." ? "localhost" : cur_machine); |
There was a problem hiding this comment.
This added line is not executed by any test.
|
Is the "old demo" video @ https://youtu.be/lvR2youiY4M still relevant, or have things changed since? Could you state that it's still what it looks and acts like or add a new video otherwise? Thanks! |
|
@garrett, the new warning on the login page looks like this:
(This is obviously terrible.) The demo https://youtu.be/lvR2youiY4M is still correct regarding the behavior. |
There was a problem hiding this comment.
Oof, yeah, I agree that is quite bad visually.
Is this to the point where it's blocking on me? (Apologies; I've been picking off issues one by one from a very long list of things that might possibly need my attention.)
Problems
- The look of it (which we all can agree... is not ideal): I'll have to fix this with CSS.
- The level of alert. This should be a warning, not an info tip.
- "You're already connected to" makes it sound like you're connecting to that specific host again. We'll need to adjust the words.
- The placement might not be the best, as it's disconnected to where you're logging in. This is somewhat subjective though, I guess.
- Actions about what you can do about it: "Go there" is obviously not correct. But this also doesn't really make it clear what you're doing or why. It's not clear what the problem actually is. You don't know why this is an issue and if you should avoid doing this or not.
- The grey button is basically invisible on a similar shade of blue. It does not stand out nor look like a button as a result.
Solutions will be...
- Better messaging
- Better warning level
- Better overall design, possibly?
- We could make it work with an alert at the top, but I'm concerned that it's too disconnected and someone wouldn't see it.
- It's also falling into what's sometimes called "banner blindness". Although this isn't an ad, it's in a place and size like one, and people have trained themselves to ignore blocks like this. https://en.wikipedia.org/wiki/Banner_blindness
- Improve style, with CSS adjustments
I think with the exception of # 2 (probably), these all require me to step in?
Should we / could we talk about this to agree upon things to make it easier and also try to prioritize this higher, since it's security-related and probably not that much work to get it to the finish line?
This is the second half of #20834.