Using cookies or Password Widget without Local storage plugin

[TW_Tones]

Folks,

When using the Single file wiki (and presumably node) I can use the password widget and it does save the named values in the local storage as viewed using the developer tools.

Once set is there anyway to access cookies or the password content from the wiki? I can use actual tiddlers if I install the Local storage plugin but I am keen to see if there is a more generic way to do this. I believe regular html developers may be able to help me with this one or is there a small gap in the tiddlywiki core when it comes to using cookies as TWC and the cookie jar etc… was so good at?

Could there be a plugin or macro that can do this already, or perhaps we can make use of code normally used when running on a server?

[jeremyruston]

It is intentional that it is not possible in wikitext to retrieve passwords set by the password widget. Otherwise it would be possible to write malicious wikitext that steals passwords.

[TW_Tones]

Understood

• But is there a way I could compare something with the password to check it matches?
  • that is the wiki needs to have the “secret” to start with, it just needs to check if the current user also does.
• It need not actually be the password but some other cookie, designed to be consumed by the wiki.

In this case it is so the current browser session can pass information to the wiki after it is reloaded in the same window.

[EricShulman]

@TW_Tones

…when it comes to using cookies as TWC and the cookie jar etc… was so good at?

Could there be a plugin or macro that can do this already…

In TWC, the “CookieJar” was a TiddlyTools creation. So, of course, i’ve re-implemented cookie handling for TW5.

Here’s a permaview to Inside TiddlyWiki — A Guide for Users, Authors, Designers and Developers, where I use cookies to track settings:

https://tiddlytools.com/InsideTW/#TiddlyTools%2FCookies%2Fcookie.js:TiddlyTools%2FCookies%2Fcookie.js%20TiddlyTools%2FCookies%2Faction-setcookie.js%20TiddlyTools%2FCookies%2Fgetcookie.js%20TiddlyTools%2FCookies%2Fcookienames.js%20TiddlyBook%2FCookieJar

Note that, by default, InsideTiddlyWiki uses the “zoomin” story view, but it DOES load the permaview. You just have to use the “history” button (clock-in-circular-arrow) in the Tiddler toolbar to view the other “open” tiddlers.

• TiddlyTools/Cookies/cookie.js
  <$cookie> widget loads and saves cookies
• TiddlyTools/Cookies/action-setcookie.js
  <$action-setcookie> widget saves a specific cookie
• TiddlyTools/Cookies/getcookie.js
  <<getcookie>> JS macro returns the value of a specific cookie
• TiddlyTools/Cookies/cookienames
  <<cookienames>> JS macro returns the names of all current cookies
• TiddlyBook/CookieJar
  tagged with $:/tags/PageTemplate, uses <$cookie> widget to automatically load cookies when page is loaded and automatically save cookies whenever TiddlyBook settings are changed.

Note that, due to browser security restrictions, cookies are not supported for file:// URLS, so these functions only apply when the file is posted online.

To see it in action, go to Inside TiddlyWiki — A Guide for Users, Authors, Designers and Developers and then change settings using the icons in the upper right corner of the window. Any settings you change – except for the lock/unlock function – are automatically saved as cookies and will be re-applied whenever you reload the URL.

enjoy,
-e

[TW_Tones]

Oh, Wow , Eric to the rescue again with his Pre-emptive innovation

I will look at your cookie jar right away, but as you can see in this thread I only want to pass a few "
cookies" is there a minimalist way, or do you think only the cookie jar can do it?

Thanks “mate” as us aussies say.

[EricShulman]

Oh, Wow , Eric to the rescue again with his Pre-emptive innovation

When I see a need, I write something, even if no one ELSE has asked for it!

I will look at your cookie jar right away, but as you can see in this thread I only want to pass a few "
cookies" is there a minimalist way, or do you think only the cookie jar can do it?

The CookieJar is simply a convenient way to invoke the ‘<$cookie>’ widget at startup (i.e, when the PageTemplate is rendered), and to automatically save settings when they change. The TiddlyBook/CookieJar is specific to the needs of the TiddlyBook implementation. You could just as well put <$cookie> widgets into a tiddler that you add to the DefaultTiddlers in the $:/ControlPanel

-e

[TW_Tones]

Eric,

I am attempting to use this solution. I am not getting consistent results but I will keep researching/testing.

Windows 10, FireFox and 5.2.0-prerelease

I did actually save and retrieve a cookie value,

but then it stopped working when I did this;

<$button>
<$action-setcookie $name="txtUserName" $value={{$:/status/UserName}} /> 
<$action-setcookie $name="txtwiki-name" $value={{$:/config/wiki-name}} />
<$action-setcookie $name="txtpathname" $value={{$:/info/url/pathname}} />
Set cookies
</$button>

In the FireFox developer tools I see;

Cookie “username” will be soon rejected because it has the “SameSite” attribute set to “None” or an invalid value, without the “secure” attribute. To know more about the “SameSite“ attribute, read SameSite cookies - HTTP | MDN

Other

• I could not find the storage in Chrome.
• There is already a Cookie TiddlyWiki containing content like this;

chkRegExpSearch:“false” chkCaseSensitiveSearch:“false” chkIncrementalSearch:“true” chkAnimate:“true” chkSaveBackups:“true” chkAutoSave:“false” chkGenerateAnRssFeed:“false” chkSaveEmptyTemplate:“false” chkOpenInNewWindow:“true” chkToggleLinks:“false” chkHttpReadOnly:“true” chkForceMinorUpdate:“false” chkConfirmDelete:“true” chkInsertTabs:“false” chkUsePreForStorage:“true” chkDisplayInstrumentation:“false” txtBackupFolder:"" txtEditorFocus:“text” txtMainTab:“tabTimeline” txtMoreTab:“moreTabAll” txtMaxEditRows:“30” txtFileSystemCharSet:“UTF-8” txtTheme:"" txtUserName:“YourName” chkCopyTiddlerDate:“false” txtIncrementalSearchMin:“3” chkPrefillNotes:“false” chkBackstage:“false”

Regards
Tony

[EricShulman]

I’ve updated cookie.js and action-setcookie.js widgets to add “SameSite=Strict” to the cookie header.
It seems to still be working on InsideTiddlyWiki, so I guess that’s good.

Try copying the updated widgets to your document and see if those console warning messages go away. Let me know.

I used to be able to view the cookie storage for Chrome by opening a browser tab to chrome://settings/cookies. Then, from that page, I could click on “see all cookies and site data”. However… when I just tried that, it showed a spinning cursor for a very long time, and then crashed the browser! So… I don’t know.

Still, I am able to put <<cookienames>> and <<getcookie "TiddlyTools">> into a tiddler on InsideTiddlywiki, and it does display all the cookienames and the value of the saved “TiddlyTools” cookie, respectively. That indicates that the cookies ARE still working. Also, when I changed settings on InsideTiddlyWiki (e.g., choose a different “theme”, like “Woodshop”, from the theme popup in the upper right corner), and then I reloaded the page, the changed settings were applied, so that also indicates that the cookies are still working.

Regarding those cookies that start with “txt” and “chk”… those are TWClassic cookie names! So I guess you’ve viewed an old TWClassic page somewhat recently (at least, since the last time your cookies were cleared).

enjoy,
-e

[TW_Tones]

Thanks Eric,

I think issues to do with the Developer tools were adding complexity.
<<cookienames>> is returning the list and now after installing the updates <<getcookie>> is returning the values.

Of particular note: I use Timimi a lot so my wikis in the browser are operating at file:///... and the cookies are working at this address.

For the record

<$list filter="[<cookienames>enlist-input[]]" variable=cookie>
   <<cookie>>: <$macrocall $name="getcookie" name=<<cookie>>/>,<br>
</$list>

And to set;

<$button>
<$action-setcookie $name="txtUserName" $value={{$:/status/UserName}} /> 
<$action-setcookie $name="txtwiki-name" $value={{$:/config/wiki-name}} />
<$action-setcookie $name="txtpathname" $value={{$:/info/url/pathname}} />
<$action-setcookie $name="txtpathname" $value={{$:/temp/password}} />
Set cookies
</$button>

Once again thanks so much for your help and foresight.

[TW_Tones]

Just a note on this whole thread.

I still do not know how to retrieve or test the password set with the password widget however I have being able to see it in plain text using the developer tools.

I no longer need to use the password widget with Eric’s cookie tools, however it would be nice if I could make use of the tool in tiddlywiki for this purpose.

I have found a reasonable alternative however since I can set passwords with obfuscation using the following;

<$edit-text tiddler="$:/temp/password" tag=input type=password/>

When this line of investigation is complete I may produce a separate how to post.

Regards

[TW_Tones]

I would like to advance this subject a little;

@EricShulman et all.

Background
Given file:// is considered the same domain for all tiddlywikis at fiIe addresses, the cookies have proven to be problematic, for my particular application, although helpful in other respects. See my workaround below. The problem is if I set a “unique” session ID in a cookie when granting access to a wiki, the shared cookies end up granting access to the same wiki in another tab.
I do note however using the developer tools in FireFox under the storage tab, we see

Question
Since we can access local storage with the local storage plugin and it remains unique to each tab I am wondering if a rewritten set of @EricShulman s cookie macros and actions could be written to address the “session storage” listed above? perhaps these could be called session-cookies. And thus they would remain private to the session, and the local storage plugin need not be used.

Using local storage for session only information
I just want to link this thread to one as a result of the observation that all cookies set for a tiddlywiki at a file:// address can be seen by all other tiddlywikis at a file:// address. Thanks to @pmario. See how I identified this as a TiddlyWiki opportunities for unlimited potential - #2 by TW_Tones

[TW_Tones]

So I tested the local storage to see if it was different for each tab to the same wiki in the same browser and the local storage was different.

Unfortunately I did not hit the refresh button on the storage, and after designing the whole solution the two sessions “overwrite each other”.

Back to the drawing board! I will update that post in time.

[TW_Tones]

Just a Quick update.

• It has become evident cookies even local storage is shared between all tabs at the same domain which is a problem if you have multiple file:// wikis. I do see this as a potential feature here TiddlyWiki opportunities for unlimited potential - #2 by TW_Tones

However I expect the session storage to be private to each tab. Although I cant write tiddlywiki compliant Javascript yet, it seems there are only a few session storage functions that are needed and the cookies macro and actions could be cloned and modified to instead refer to session values.

This could have quite a bit of value especially along side cookies and shared storage.