TiddlyWiki / TiddlyWiki5

A self-contained JavaScript wiki for the browser, Node.js, AWS Lambda etc.
https://tiddlywiki.com/
Other
8.04k stars 1.19k forks source link

Blocking cookies prevents uploading to TiddlySpot #3955

Closed twMat closed 5 years ago

twMat commented 5 years ago

Maybe obvious to everyone but me, but apparently setting the browser to block third-party cookies in Chrome prevents uploading to TiddlySpot.

It is worth noting that I have probably not set this block directly myself. More likely, it has been a consequence of some security extension I've installed that did it for me. However, I guess that because it is a native browser setting (and because extensions are not always carefully designed) the state of the setting persists even if I disable all extensions or even delete them. Further, syncing the browser across devices transfers this setting. I guess that is what syncing is for but it means problem like this are transferred both between devices and also through time i.e when I've diligently updated hoping the problem was a bug of sort. However, and this is the most frustrating aspect; it seems that if I log into my browser account for syncing, then this browser setting stays persistent even if I log out! This is evidenced from the fact that I have on occasions succeeded in uploading to TS, e.g on a new Windows user account on a computer, only to fail later after having synced and then logged out.

This is all outside of TiddlyWiki but it has been an extremely persistent problem for me and it has, to name one thing, severely affected my contributions to the community because I use TiddlySpot as my ubiquitous server for publishing stuff.

In practice Clicking Save to upload from local has instead opened the download dialogue, asking me where I want to (re-)save the file locally. One confusion in this is that along with the download dialogue, the small yellow TW popup is triggered that states "Saved wiki" i.e before I've either cancelled the download or OK'ed it. It seems to be triggered merely from clicking the TW Save button but the file is, AFAICT, not saved anywhere yet.

Proposal "Make uploading to TS work". I won't elaborate on this because I don't have the technical knowledge. Now, I don't expect this to be possible to control from TW in which case the proposal humbles down to merely updating the docs to inform about this issue. I can author this if a better solution is not possible.

pmario commented 5 years ago

Hi, I had a closer look. I can reproduce the behaviour you describe, if the password isn't set.

The browser developer tools shows no sign of cookies with tiddlyspot. ... IMO there are no cookies.

But you are right. There should be "Save in progress" banner or something similar.

twMat commented 5 years ago

Thanks for reply pmario! It first made me discouraged but I then realized that you're right because it is not TS that sets cookies; instead it is probably the password in the local TW that is interpreted(?) as a cookie and blocked. (Make sure to reload the page in between tests while - at least in Win - pressing the Shift key to really refresh without cache.)

The Chrome setting is this one:

Capture
twMat commented 5 years ago

@pmario or anyone curious - Not sure it is relevant but if it, in whatever inspector tool you're using, is not possible to see a cookie related to the password (...and that is just a theory but it is definitely the cookie block that messes it up) then possibly this thread has some info for testing stuff?

pmario commented 5 years ago

With TS the password is sent in clear text like this: http://2721:xxxxxxx@2721.tiddlyspot.com/store.cgi where xxxxxxx is the password. That's why you should never use a PW for TS that you also use for other services. ... Because everyone can see it.

pmario commented 5 years ago

I'm using F12 dev tools in the browser. ... Select the "Network" tab and activate the "Save Button"

You'll see a POST command. After the save is done, you can select the command and you can see the URL that is used to save the TW. ... May be this setting modifies or blocks plain text passwords, because of security reasons. ...

I'm testing with FF. Chrome is not installed on my system.

AnthonyMuscio commented 5 years ago

As mentioned by me in the discussion even if you set a global setting for the "browser to block third-party cookies" you can set a specific site to be permitted.

I understand how cookies etc... can be used for ill, but simply not enabling this intrinsic method for driving the internet is going to have unpleasant results. If you wish to keep this setting I suggest, wisely enabling it for the sites where you are confident it is safe. Try incognito modes for occasional ventures into the possibly dubious web.

If a security tool does not permit this override, and you can't use the browsers exception list, you will just have to provide the information that is missing, if possible at the time it is required, because, well you have asked the browser not to provide this information.

I know this view may not meet with others "value judgements" on a security stance, and I expect a diversity of views on this. I just wanted to share my point of view.

Regards Tony

Regards Tony

pmario commented 5 years ago

As I wrote. There are no cookies at tiddlyspot.

Jermolene commented 5 years ago

Hi @twMat I can confirm the problem. The upload saver uses local storage for storing the password, and the mechanism fails when it is not available. Fix upcoming.

Jermolene commented 5 years ago

Please give the prerelease a try in about 10 minutes once the build has finished. (By the way, you can see build status here: https://travis-ci.org/Jermolene/TiddlyWiki5/builds).

twMat commented 5 years ago

@Jermolene - thank you!!! Not only for solving it but also for confirming it.