..cookies are bad mmkay
Simon Baird
What happened indeed...---------- Forwarded message ----------
From: John ... <j...@gmail.com>
Date: Fri, Sep 12, 2008 at 2:03 PM
Subject: Username is inconsistent?
To: feed...@tiddlyspot.comWhen I first posted to my tiddlywiki (.....tiddlyspot.com) it asked me for a username, which I input. Now, however, having come back another day and made changes, the username the changes are posted under is simply...'Yourname'.
What happened?
Here's another (hypothetical) question from a new user "I have two TWs and I want autosave on in one and off in another..... What happened?"
This is the kind of confusion we subject people to every day because TiddlyWiki uses cookies for configuration. I've ranted about this from time to time... (And yes I am aware of the no doubt very capable cookie jar baking system that Eric has crafted as a power user solution to this TiddlyWiki design flaw).
Well instead of my usual subtle whinging and occasional ranting about how I don't like the cookie based configuration system, today I have a proposal:
Lets save all config.txtBlah and config.chkBlah values in a tiddler called SystemSettings. (It could be a slice in the body of that tiddler, or it could be done with tiddler fields, probably fields would be better). Instead of reading the values from cookies at startup read them from there. Make a version of the option macro that reads and writes from the SystemSettings tiddler instead of the (gosh darned) cookies. Rejoice.
Now the common response is 'but what about per user preferences on a published TW, or what about setting the username on a TW shared between different people?'. This is a valid point. But the debatable -- for me TW is a single user app -- usefulness of these features is dwarfed by the huge inconvenience and confusion we subject TW users to with the current system.
Oops, I guess that was another rant... :)
Simon.
Ps, and guess what, Chrome doesn't do cookies for local files. Not because it's buggy. But because it's kind of a bad idea.
Paul Downey
> Lets save all config.txtBlah and config.chkBlah values in a tiddler
> called SystemSettings. (It could be a slice in the body of that
> tiddler, or it could be done with tiddler fields, probably fields
> would be better). Instead of reading the values from cookies at
> startup read them from there. Make a version of the option macro
> that reads and writes from the SystemSettings tiddler instead of the
> (gosh darned) cookies. Rejoice.
Sounds like a worthwhile experiment, a valid plugin in its own right.
I'm not sure where best best place to store the options - as extended
fields which are easily read/write, or as slices - native TW text with
no need for view/edit template and macro jiggery-pokery or row-locking
when multiple event handlers update options.
> Now the common response is 'but what about per user preferences on a
> published TW, or what about setting the username on a TW shared
> between different people?'. This is a valid point. But the debatable
> -- for me TW is a single user app -- usefulness of these features is
> dwarfed by the huge inconvenience and confusion we subject TW users
> to with the current system.
For the shared TW on a server, a session cookie could be legitimately
be used to identify the user and switch in the appropriate options
tiddler, either server or client side. If we're clear on the
constraints, how that's implemented could be left to the capable hands
of TiddlySpot, ccTiddly, TiddlyWeb, etc.
There does seem to be several different dimensions to the current use-
cases for options: http, ftp, file URis, files on shared drives (v)
authoring and viewer options (v) single, multi-user scenarios. And
then there is backwards compatibility.
To help make progress, I'll seed a wiki page to enumerate the
different use-cases and report back.
> Oops, I guess that was another rant... :)
Oh but such a good one!
> Ps, and guess what, Chrome doesn't do cookies for local files. Not
> because it's buggy. But because it's kind of a bad idea.
Well, I'm not entirely convinced of that, well no more than HTTP
cookies are a bad idea too, which they probably are.
Paul Downey
> different use-cases and report back.
Anthony Muscio
Most of the cookie problems are when they go missing. Is this ignorant for me to suggest; that the cookies are otionaly saved in tiddlywiki, then at load time those that are missing are restored from the saved cookies ?
A force option could be set for each saved cookie to optionally force it's value if required ?
Having a optionConfig or cookieConfig tagged tiddler would be good, such that tiddlers with required saved cookie sets, could be included from other wikis then applied.
Perhaps a macro to to apply the cookies in a named tiddler would also alow more advanced use of cookies as variables, these are possibly a bit easyer than using java variables.
I understand the cookie jar does some or all of this, I would just like it to be simpler and an embeded part of the core. Who leaves local and global variable definitions outside there core normaly ?
I hope my contrribution is of value.
TonyM
Anthony Muscio
FND
document settings and user preferences.
While most options can (and should) be "baked" into in the document,
there are some can and should not.
> [user options are] a valid point. But the debatable -- for me TW is a
> single user app
We have to cover all use cases though, not just look at our individual
preferences.
> the cookies are otionaly saved in tiddlywiki, then at load time those
> that are missing are restored from the saved cookies
I'd take a slightly different approach, with pretty much the same
outcome; cookie settings take precedence over hardcoded settings.
I've talked to Jeremy about this, and I believe he'll be looking into
implementation options.
-- F.
Anthony Muscio
"Cookie settings take precedence over hardcoded settings".
I suggest this can be overridden, but not by default.
As I said the problem for me is nearly always missing cookies, not ones with wrong values.
Cookies are transportable across sessions and time, this should be retained.
Perhaps a better approach is to investigate why we are always loosing them.
TonyM
Anthony Muscio
Eric Shulman
> TiddlyWiki uses cookies for configuration. I've ranted about this from time
> to time... (And yes I am aware of the no doubt very capable cookie jar
> baking system that Eric has crafted as a power user solution to this
> TiddlyWiki design flaw).
> SystemSettings. (It could be a slice in the body of that tiddler, or it
> could be done with tiddler fields, probably fields would be better). Instead
> of reading the values from cookies at startup read them from there. Make a
> version of the option macro that reads and writes from the SystemSettings
> tiddler instead of the (gosh darned) cookies. Rejoice.
http://www.TiddlyTools.com#CookieSaverPlugin
It does pretty much what you have described, except that I am using
[[CookieJar]] instead of [[SystemSettings]] as the name of the in-
document repository of settings. Also, rather than using tiddler
slices or fields, CookieSaverPlugin actually generates a line of
javascript code to directly assign each saved option value to their
corresponding internal config.options.* variables.
To process the contents of the [[CookieJar]], it is simply tagged with
'systemConfig' so it will be invoked during startup like any other
plugin, without needing any special code in the core to process it!
As a result, "Portable Cookies" that are stored in the [[CookieJar]]
are applied each time the document is loaded in the browser,
regardless of whether or not there are any local browser cookies
defined as well.
... and all of this happens without any user intervention:
The plugin hijacks the core's saveOptionCookie() function, and
introduces a new inverse function, removeOptionCookie(), so that it
can catch each 'cookie changing' event and automatically record the
same changes directly into the [[CookieJar]]. Except for the need to
save the file in order to save the changes to the [[CookieJar]], the
user doesn't have to do anything special at all! The stored settings
just show up in the [[CookieJar]], and they travel with the document
rather than being stuck inside the browser, so their settings will be
applied each time that document is viewed, no matter what browser they
are using at the moment.
> Now the common response is 'but what about per user preferences on a
> published TW, or what about setting the username on a TW shared between
> different people?'. This is a valid point. But the debatable -- for me TW is
> a single user app -- usefulness of these features is dwarfed by the huge
> inconvenience and confusion we subject TW users to with the current system.
contain multiple sets of portable cookies, each of which is associated
with a different user name (i.e., whatever username was in effect when
the portable cookies were stored in the [[CookieJar]]), and there is
also a 'cookie blocking' feature that allows you to block individual
named cookies from being written to the [[CookieJar]] in order to
bypass the potential for saving sensitive, private cookie data within
a tiddler that might be viewed by others.
Of course, you can always tag the [[CookieJar]] with 'excludeLists' to
make it harder to view. However, while 'excludeLists' can discourage
the idly curious from seeing private information, it does not provide
any real defense against someone who is determined to dig around...
and certainly doesn't prevent the underlying tiddler data from being
directly examined by using a text editor.
In any event, give the CookieSaverPlugin+CookieManagerPlugin+CookieJar
a try and let me know what you think...
enjoy,
-e
Eric Shulman
TiddlyTools / ELS Design Studios
Jeremy Ruston
with Simon's assessment, and closely agree with his proposed solution.
Some history: the option and cookie mechanism was first implemented
just so that I could make the right hand tabs "sticky"; I just wanted
it so that when you revisited a TW page the tabs would stay how you
left them. The mechanism I implemented was more or less the minimal
thing that would support that scenario, whilst decoupling client code
from the intricacies of cookie interactions. Settings of that class
are disposable, in the sense that if you lose them it doesn't matter
very much.
Once the mechanism was in, it then got used for all kinds of stuff
that isn't volatile in the same way, like the username, giving rise to
the problems that Simon lists. I'd still contend that the original
motivation for sticky convenience settings still exists, for a small
set of UI furniture.
Anyhow, we are where we are: we've got a reasonably well defined API
for plugins (and the core code) to access and modify settings, and a
cookie-based persisting mechanism. I think a reasonable goal is to
extend the existing options mechanism to support both cookies and
file-baking, keeping the API as far as possible the same.
I favour keeping the baked options as slices in a SystemSettings
tiddler, and not fields, because there's some pedagogic value in
exposing the mechanism, not to mention allowing manual edits in a
natural way for bulk option modifications.
In order to allow the baked settings to co-exist with cookie settings,
I propose that a special value in SystemSettings can be used that says
"this setting lives in a cookie". One simple way that we could do that
would be like this:
|chkUserName |JeremyRuston |
|chkAnimate/cookie |true |
Here, chkUserName is given a hardcoded value. Any cookie named
chkUserName will be ignored, and not updated. chkAnimate, in contrast,
is marked as being stored in a cookie, with the default value "true"
if the cookie is not present.
I hope that makes sense. I'm hoping that this proposal is fully
backwards compatible, and still reasonably straightforward to
implement.
Best wishes
Jeremy
--
Jeremy Ruston
mailto:jer...@osmosoft.com
http://www.tiddlywiki.com
FND
> In order to allow the baked settings to co-exist with cookie settings,
> I propose that a special value in SystemSettings [...]
> One simple way that we could do that would be [to use "/cookie" as suffix]
Using a prefix in the slice name seems somewhat, well, abusive to me.
Also, the respective precedence (cookie or hardcoded value) might not be
immediately transparent to users that way.
FWIW, Paul has expressed interest in writing a plugin to introduce a new
type of slice that supports multiple key-value pairs (essentially
turning tables into objects) - maybe something like that could be used
instead? (There are various issues with that, of course - just wanted to
point out the possibility.)
-- F.
Jeremy Ruston
> Also, the respective precedence (cookie or hardcoded value) might not be
> immediately transparent to users that way.
The obvious way to do it would be something like this:
|txtUserName: |*cookie* |
The problems would come when someone wanted to store the value "*
cookie *" in an option...
You're right, though, some more expressiveness in the slice syntax
might be handy sometimes.
Cheers
Jerm
> FWIW, Paul has expressed interest in writing a plugin to introduce a new
> type of slice that supports multiple key-value pairs (essentially
> turning tables into objects) - maybe something like that could be used
> instead? (There are various issues with that, of course - just wanted to
> point out the possibility.)
>
>
> -- F.
>
> >
>
--
Jeremy Ruston
http://trac.tiddlywiki.org/ticket/756
It adds a new shadow tiddler called SystemSettings that contains
name:value pairs giving the values for various settings. For example:
chkAnimate: false
txtUserName: JeremyRuston
By default, cookies are not involved; if a setting is changed, then
the SystemSettings tiddler is modified, triggering a save of the
entire document.
If an author wants an option specifically to be stored in a cookie,
append "_cookie" to the option name. The value then becomes the
default value used if the cookie isn't present.
For example:
chkAnimate_cookie: true
This causes chkAnimate to be initialised to "true", but it can be
overridden by a cookie.
That "*_cookie" mechanism is obviously very clunky, and I'm interested
in cleverer suggestions. There are a few other rough edges to be dealt
with too.
It's worth discussing why I haven't followed Eric's elegant idea of
using executable JavaScript in a systemConfig tiddler to store and
apply the baked options. My concern is that that mechanism requires
the user to have permissions to create/modify tiddlers tagged
systemConfig, which wouldn't be the case for some security-conscious
serverside implementations.
Cheers
Jeremy
Simon Baird
(I'll try and do some testing soon time permitting...)
I've uploaded a patch for discussion:
Jeremy Ruston
> work with this patch?
Yes, it does work just as before. It probably could do with updating
to indicate whether an option is currently stored in a cookie or not.
I've also just seen Eric's ticket for deleting cookies:
http://trac.tiddlywiki.org/ticket/757
I'll look at refactoring it so that resetting a cookie-d option to
it's default option deletes the cookie.
Best wishes
Jerm
> (I'll try and do some testing soon time permitting...)
>
> On Tue, Sep 23, 2008 at 12:51 AM, Jeremy Ruston <jeremy...@gmail.com>
> wrote:
>>
>> I've uploaded a patch for discussion:
>>
>
>
> --
> simon...@gmail.com
>
> >
>
--
Eric Shulman
> the SystemSettings tiddler is modified, triggering a save of the
> entire document.
document store to 'dirty as it normally does when a tiddler is
modified (unless, of course, autosave is enabled)?
It's important to note that cookies are being set by the core all the
time, not only in response to explictly changing a setting, but also
as side-effects of normal, interaction with sliders and tabs, which
use cookies to track their current state.
Keeping slider and tab info in "real" browser cookies still makes
sense, since these states are transitory and ephemeral, yet often
people want them to persist on a per-user, cross-session basis...
which is *exactly* what cookies are intended for!
> If an author wants an option specifically to be stored in a cookie,
> append "_cookie" to the option name. The value then becomes the
> default value used if the cookie isn't present.
> using executable JavaScript in a systemConfig tiddler to store and
> apply the baked options. My concern is that that mechanism requires
> the user to have permissions to create/modify tiddlers tagged
> systemConfig, which wouldn't be the case for some security-conscious
> serverside implementations.
is to create tiddlers such as [[ConfigTweaks]] or [[CookieJar]] that
are tagged with 'systemConfig' and contain javascript assignment
statements that are invoked *after* the browser's cookies are read
into TW internal config.options.* variables.
The result is that the hard-coded values (aka, "portable cookies")
stored in a CookieJar tiddler will override the browser's local cookie
values. For example:
config.options.chkAnimate=false;
forces animation to always be disabled, regardless of any browser
cookie value the might be present. The proposed [[SystemSettings]]
tiddler would invert this behavior, so that local cookie values will
take precedence over stored "portable cookie" values.
Of course, depending upon the specific use-case, this new behavior
could be just as desirable as the current one. Fortunately, because
the ConfigTweaks/CookieJar is written using javascript syntax, it
possible to add a simple conditional test function to determine if a
browser cookie is already defined for that any given setting and only
assign the hard-coded value if no cookie exists:
function isCookie(c)
{ return document.cookie.indexOf(c)!=-1; }
if (isCookie("chkAnimate"))
config.options.chkAnimate=false;
Thus, depending upon the use case, it is possible to choose either
approach on a cookie-by-cookie basis simply by including or omitting
the conditional test preceding the assignment statement.
Another problem that must be addressed is the storage of user-specific
settings:
By definition, browser-based cookies are always user-specific
(especially if each user has their own computer, which is most often
the case). In order to truly replace browser-based cookies with 'in
document' storage, any mechanism that stores settings within a tiddler
has to be able to somehow prevent those settings from being
automatically applied to other users as soon as they view the
document.
Again, javascript syntax in the ConfigTweaks/CookieJar makes it easy
to
define and apply a suitable conditional test function to create user-
specific settings:
function isUser(u)
{ return config.options.txtUserName==u; }
if (isUser("SomeName")) config.options.chkAnimate=true;
Of course, it is also possible to set several internal values at the
same time, based on a single test condition. For example, the
following is *very* useful for selectively enabling/disabling readonly
vs. 'full editing' modes of operation:
readOnly=!isUser("AdminName");
showBackstage=isUser("AdminName");
config.options.chkHttpReadOnly=!isUser("AdminName");
Take note that that two of these settings are not actually stored as
cookies at all... rather, they are TW internal operating flags that
have been automatically calculated at startup, but are then overridden
using the above code.
Jeremy Ruston
deleting unnecessary cookies:
http://trac.tiddlywiki.org/ticket/756
I'm now wondering whether I shouldn't also tackle this ticket (packing
all options into a single cookie to get around the max cookies limit
on some browsers) at the same time:
http://trac.tiddlywiki.org/ticket/206
Cheers
Jerm
Jeremy Ruston
options values into a single cookie (named "TiddlyWiki"), which should
avoid the limits that some browsers place on the number of cookies
that can be set by a single domain:
http://trac.tiddlywiki.org/ticket/756
Cheers
Jeremy
FND
That's definitely a good thing to have.
On a more general note, I think we should simplify this:
SystemSettings only contains settings that have been deliberately
hardcoded ("baked") into the document. All remaining options are
considered volatile preferences - so they are stored in cookies (if the
browser allows this - otherwise, it's no big deal).
So essentially, SystemSettings does what we currently need manually
created ConfigTweaks tiddlers for.
Unless I'm missing something, that's perfectly backwards-compatible, is
transparent to end-users, does not lead to unexpected behavior (e.g.
AutoSave), and also gets rid of ugly suffixes like "_cookie".
Thoughts?
-- F.
Hans
I'm new here in the TiddlyWikiDev group, but i joined because I'm very
interested in TiddlyWiki. I've been using it for about 3 days right
now. I love the flexible architecture, and the endless posibilities.
I'm using it all day long, keeping my notes in it etc. and I store
my .html on a USB-stick.
Now; I had some problems with the cookies, and I don't like the
plugin; so i found this discussion. Now I've been looking into the
patches, and patching my local copy so it will work. And I've got some
remarks for the latest patch.
How can I join the development team? Is it open (anyone can join) or
closed? I think I can contribute to this project.
Some questions about the code patch:
js/main.js
line 42: loadOptionsCookie();
js/Options.js
line 42: var loadOptionsCookie = initialiseOptions;
Why still use the old depricated function name?
js/Options.js
line 75-83:
75 var splitPos = key.indexOf('_');
76 var name = key;
77 var source = "setting";
78 if(splitPos !== -1) {
79 source = key.substr(splitPos+1);
80 name = key.substr(0,splitPos);
81 }
82 setOption(name,settings[key]);
83 config.optionSource[name] = source;
line 137: if(config.optionSource[key] == undefined ||
config.optionSource[key] == "setting") {
What if someone names the option in the SystemSettings shadow tiddly
as; testOption_test.
This will not be saved (the source will be 'test', and line 137
says...), also this might be a normal name for a property?
I hope this information makes the patch better.
After patching my local HTML, it won't run anymore;
"Popup.onDocumentClick" -error?!
Cheers,
Hans.
On Sep 24, 3:05 pm, "Jeremy Ruston" <jeremy.rus...@gmail.com> wrote:
> OK, I've posted another revised patch. This one now packs all of the
> options values into a single cookie (named "TiddlyWiki"), which should
> avoid the limits that some browsers place on the number of cookies
> that can be set by a single domain:
>
> http://trac.tiddlywiki.org/ticket/756
>
> Cheers
>
> Jeremy
>
>
>
>
>
> On Tue, Sep 23, 2008 at 5:05 PM, Jeremy Ruston <jeremy.rus...@gmail.com> wrote:
> > I've uploaded an updated patch that includes Eric's suggestion for
> > deleting unnecessary cookies:
>
> >http://trac.tiddlywiki.org/ticket/756
>
> > I'm now wondering whether I shouldn't also tackle this ticket (packing
> > all options into a single cookie to get around the max cookies limit
> > on some browsers) at the same time:
>
> >http://trac.tiddlywiki.org/ticket/206
>
> > Cheers
>
> > Jerm
>
> >>> Looks nice and easy. I wondered about the options macro. Does that still
> >>> work with this patch?
>
> >> Yes, it does work just as before. It probably could do with updating
> >> to indicate whether an option is currently stored in a cookie or not.
>
> >> I've also just seen Eric's ticket for deleting cookies:
>
> >>http://trac.tiddlywiki.org/ticket/757
>
> >> I'll look at refactoring it so that resetting a cookie-d option to
> >> it's default option deletes the cookie.
>
> >> Best wishes
>
> >> Jerm
>
> >>> (I'll try and do some testing soon time permitting...)
>
>
> >>>> I've uploaded a patch for discussion:
>
> >>> --
> >> --
> >> Jeremy Ruston
> >> mailto:jer...@osmosoft.com
> >>http://www.tiddlywiki.com
>
> > --
> > Jeremy Ruston
> > mailto:jer...@osmosoft.com
> >http://www.tiddlywiki.com
>
> --
> Jeremy Ruston
>
> - Show quoted text -
Paul Downey
Hello Hans!
> I'm new here in the TiddlyWikiDev group, but i joined because I'm very
> interested in TiddlyWiki. I've been using it for about 3 days right
> now. I love the flexible architecture, and the endless posibilities.
> I'm using it all day long, keeping my notes in it etc. and I store
> my .html on a USB-stick.
cool!
> Now; I had some problems with the cookies, and I don't like the
> plugin; so i found this discussion. Now I've been looking into the
> patches, and patching my local copy so it will work. And I've got some
> remarks for the latest patch.
> How can I join the development team? Is it open (anyone can join) or
> closed? I think I can contribute to this project.
Well anyone can develop TiddlyWiki, natch, but if you want a change
to appear in the core release of TiddlyWiki, then suggest raising a
ticket on trac, ideally with a patch:
and the current core committers can review it ..
we should be able to set you up with a user on the TiddlyWiki
subversion repo, if you'd find one useful:
many of us develop plugins and verticals (editions of TiddlyWiki)
in our individual contributor directories:
http://svn.tiddlywiki.org/Trunk/contributors/
you can build a TW from a set of small individual files using
various tools:
http://tiddlywiki.org/wiki/Dev:Tools
> Some questions about the code patch:
ah, I'll let someone else answer that - it's too late on Saturday
night for me to focus on that :)
Best,
Paul (psd)
--
http://blog.whatfettle.com