Skip to content
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

How to check if the TW is read-only on frontend? #326

Open
YakovL opened this issue Feb 15, 2024 · 2 comments
Open

How to check if the TW is read-only on frontend? #326

YakovL opened this issue Feb 15, 2024 · 2 comments

Comments

@YakovL
Copy link
Contributor

YakovL commented Feb 15, 2024

Currently, the ThostUploadPlugin for TWC has this bit: window.readOnly = false; However, it's sometimes desirable to understand whether the TW is in fact read-only (a non-owner has opened the site; the owner is not logged it).

Is there a simple way to check that on frontend? What endpoint to use?

I think, the proper approach would be to

  1. set window.readOnly = false; or true on backend depending on the initial auth and rights and
  2. with a frontend method to check the auth status, I can add some logic to the plugin which will help checking/updating readOnly/refreshing things.

So besides my first question, I'd like to learn if there's a method or variable available to amend the initial value like window.readOnly = <%= has_user_editor_rights ? 'false' : 'true' %>

@simonbaird
Copy link
Collaborator

For TiddlyWiki5, Tiddlyhost writes either 'yes' or 'no' to a tiddler called $:/status/IsLoggedIn based on whether the user is logged in. So I expect we can find a way to do what you're looking for.

Do you think this should be the default behavior always? I'm wondering there are users who would prefer the "Edit" button to be visible even when the site can't be saved.

@YakovL
Copy link
Contributor Author

YakovL commented Feb 18, 2024

Right, so the first approximation would be window.readOnly = <%= status_is_logged_in ? 'false' : 'true' %>, right?

The "edit" button when readOnly == true is substituted with the "view" button (see TiddlyTools, for example), so I don't think there's any UX issues because of such a check. So yeah, I think it's safe to make this change.

What about an endpoint to check if the user has actually logged in/out after opening the page, is there such an endpoint?

simonbaird added a commit that referenced this issue Apr 21, 2024
If you're viewing a TiddlyWiki Classic site isn't your own, or is
your own but you're not logged in, previously the edit buttons would
be shown regardless of the value of the chkHttpReadOnly "advanced
options" cookie.

Now, the chkHttpReadOnly value will be respected, unless the site
owner is currently logged in.

The way it works is to inject a shadow tiddler with content set to
either 'yes' or 'no', then read the value of that tiddler in the
upload plugin. This is similar to the TiddlyWiki5 method, except in
TiddlyWiki5 the tiddler used is '$:/status/IsLoggedIn'.

Closes issue #326.
simonbaird added a commit that referenced this issue Jun 16, 2024
If you're viewing a TiddlyWiki Classic site isn't your own, or is
your own but you're not logged in, previously the edit buttons would
be shown regardless of the value of the chkHttpReadOnly "advanced
options" cookie.

Now, the chkHttpReadOnly value will be respected, unless the site
owner is currently logged in.

The way it works is to inject a shadow tiddler with content set to
either 'yes' or 'no', then read the value of that tiddler in the
upload plugin. This is similar to the TiddlyWiki5 method, except in
TiddlyWiki5 the tiddler used is '$:/status/IsLoggedIn'.

Closes issue #326.
simonbaird added a commit that referenced this issue Jun 16, 2024
There are some pros and cons to this, e.g. with this change, a user
with an expired login session might be confused about why they can
no longer save. On the other hand showing the "save to tiddlyhost"
button when a save is not possible is also potentially confusing.
Anyway, let's try it this way and see how we like it.

Closely related to the changes in the previous commit for
issue #326.
simonbaird added a commit that referenced this issue Jun 16, 2024
If you're viewing a TiddlyWiki Classic site isn't your own, or is
your own but you're not logged in, previously the edit buttons would
be shown regardless of the value of the chkHttpReadOnly "advanced
options" cookie.

Now, the chkHttpReadOnly value will be respected, unless the site
owner is currently logged in.

The way it works is to inject a shadow tiddler with content set to
either 'yes' or 'no', then read the value of that tiddler in the
upload plugin. This is similar to the TiddlyWiki5 method, except in
TiddlyWiki5 the tiddler used is '$:/status/IsLoggedIn'.

Closes issue #326.
simonbaird added a commit that referenced this issue Jun 16, 2024
There are some pros and cons to this, e.g. with this change, a user
with an expired login session might be confused about why they can
no longer save. On the other hand showing the "save to tiddlyhost"
button when a save is not possible is also potentially confusing.
Anyway, let's try it this way and see how we like it.

Closely related to the changes in the previous commit for
issue #326.
simonbaird added a commit that referenced this issue Jun 16, 2024
If you're viewing a TiddlyWiki Classic site isn't your own, or is
your own but you're not logged in, previously the edit buttons would
be shown regardless of the value of the chkHttpReadOnly "advanced
options" cookie.

Now, the chkHttpReadOnly value will be respected, unless the site
owner is currently logged in.

The way it works is to inject a shadow tiddler with content set to
either 'yes' or 'no', then read the value of that tiddler in the
upload plugin. This is similar to the TiddlyWiki5 method, except in
TiddlyWiki5 the tiddler used is '$:/status/IsLoggedIn'.

Closes issue #326.
simonbaird added a commit that referenced this issue Jun 16, 2024
There are some pros and cons to this, e.g. with this change, a user
with an expired login session might be confused about why they can
no longer save. On the other hand showing the "save to tiddlyhost"
button when a save is not possible is also potentially confusing.
Anyway, let's try it this way and see how we like it.

Closely related to the changes in the previous commit for
issue #326.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants