-
-
Notifications
You must be signed in to change notification settings - Fork 10.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Private site mode preview UX #10995
Labels
Comments
Should someone logged into the admin also be logged into the "members" site too? 🤔 |
kevinansfield
added a commit
to kevinansfield/Ghost-Admin
that referenced
this issue
Aug 8, 2019
closes TryGhost/Ghost#10995 - when first loading the site preview, if private mode is enabled submit the login form in the background to get the cookie before loading the iframe - refactors post-authentication preloading to ensure it occurs before post-authentication route hooks are called - adds `showSuccess` attribute to `<GhTaskButton>` so that when set to `false` it can stay in the running state after "success" to avoid state change flashes whilst waiting for a transition
kevinansfield
added a commit
to kevinansfield/Ghost-Admin
that referenced
this issue
Aug 8, 2019
closes TryGhost/Ghost#10995 - when first loading the site preview, if private mode is enabled submit the login form in the background to get the cookie before loading the iframe - refactors post-authentication preloading to ensure it occurs before post-authentication route hooks are called - adds `showSuccess` attribute to `<GhTaskButton>` so that when set to `false` it can stay in the running state after "success" to avoid state change flashes whilst waiting for a transition
kevinansfield
added a commit
to TryGhost/Admin
that referenced
this issue
Aug 12, 2019
…#1286) closes TryGhost/Ghost#10995 - when first loading the site preview, if private mode is enabled submit the login form in the background to get the cookie before loading the iframe - refactors post-authentication preloading to ensure it occurs before post-authentication route hooks are called - adds `showSuccess` attribute to `<GhTaskButton>` so that when set to `false` it can stay in the running state after "success" to avoid state change flashes whilst waiting for a transition
peterzimon
pushed a commit
to kevinansfield/Ghost-Admin
that referenced
this issue
Aug 13, 2019
…TryGhost#1286) closes TryGhost/Ghost#10995 - when first loading the site preview, if private mode is enabled submit the login form in the background to get the cookie before loading the iframe - refactors post-authentication preloading to ensure it occurs before post-authentication route hooks are called - adds `showSuccess` attribute to `<GhTaskButton>` so that when set to `false` it can stay in the running state after "success" to avoid state change flashes whilst waiting for a transition
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
There's a bit of semi-broken UX which I keep bumping into, and have also seen confusing people when I'm onboarding them to a new Ghost site:
If a Ghost site is in "private mode" and someone logs in: Their first landing page after login is another page asking for a password (the 'view site' iframe) -- and what I've seen multiple people do is try to enter their same user password again, and then get even more confused about why it now says "wrong password"
Particularly on Ghost(Pro), we already have a 2-password problem of ghost.org/ghost -- which now becomes a 3-password problem of needing different logins for ghost.org/ghost/ghost-front-end, and it's fairly unreasonable to expect an end user to be able to understand all of this.
I think there are probably multiple potential solutions to this, but IMO if someone is already logged into admin then they should really be automatically authenticated to private site mode without needing the private-site pass phrase?
The text was updated successfully, but these errors were encountered: