TiddlyWebWiki: issues with switching users
Oveek
intranet with one or two users to help me test.
Went through a bit of a rough patch with my computers on the fritz,
but things are pretty much straightened out now.
I'm excited by the prospect of getting closer to realizing the myriad
collaboration possibilities I've been dreaming up.
There are various areas I hope to smooth out before a major deployment
though and I'll bring them up in separate posts. I've got a list :)
There are two issues with switching between users, one IE specific.
1) txtUserName is not being set properly under IE after switching
between users. I think this is related to IE's cookie handling. Here
are the steps to reproduce:
* Under IE login to TiddlyWeb as User1.
* Open a wiki from a recipe. Expand the options panel in the sidebar
to see the username text box which will correctly show User1.
* Go back to the challenger and log in as User2.
* Open up the wiki from the same recipe. Check the username textbox
and it will still show User1 instead of User2.
The TiddlyWebConfig plugin sets config.options.txtUserName in the
statusCallBack() method. The source of the user name is
context.serverStatus.username. After repeating the above steps in
Firefox, context.serverStatus.username has the correct new value of
User2. However, after repeating the same steps in IE,
context.serverStatus.username has the old value of User1.
I'm trying to figure out where the old username is coming from. My
guess is this is related to cookies. IE doesn't immediately write
modified cookie values back to the actual file. So after doing the
above, the cookie file still has User1 in txtUserName, even though the
user changed to User2. The odd thing is that document.cookie has the
correct new value. Now I don't actually know where
context.serverStatus.username gets set. I started tracing it back, but
I became cross eyed and fell out of my chair. I think it comes from
userParams but I'm not too sure.
For now I've commented out the part that sets the username in
TiddlyWebConfig, and did my own thing that sets it correctly in a
different plugin/macro I wrote that shows the currently logged in
user. I set the username by grabbing the value from document.cookie.
The correct fix should be to find where context.serverStatus.username
is getting the old username from.
2) This problem happens when switching between users that have
different roles and is a byproduct of pages being cached. I didn't
have this problem in IE which I assume didn't cache the wiki page
whereas Firefox did.
Say User2 has write access on a bag, but User1 doesn't.
* Login as User1 and open a wiki from a recipe containing the bag
mentioned above.
* Open a tiddler from that bag, and since User1 doesn't have write
access, the tiddler will only present a view link rather than an edit
link.
* Go back to the challenger and login as User2.
* Reopen the wiki from the same recipe and look at the same tiddler as
before. The tiddler still shows only a view link even though you're
now logged in as User2 with write access on the bag.
* Clear the cache, reload the page, and view the same tiddler. Now the
tiddler will show the edit link as it should.
Appending a nocache string on the url would stop the page from being
cached, but in most cases having the page cached is a good thing.
...More stuff to come in due course.
Chris Dent
On Aug 27, 2009, at 5:21 AM, Oveek wrote:
> Hey guys, I've started a very limited tiddlywebwiki deployment on our
> intranet with one or two users to help me test.
\o/
> There are various areas I hope to smooth out before a major deployment
> though and I'll bring them up in separate posts. I've got a list :)
*hides*
> 1) txtUserName is not being set properly under IE after switching
> between users. I think this is related to IE's cookie handling. Here
> are the steps to reproduce:
This may be related to how IE is doing caching of requests back to /
status from the TiddlyWebConfig plugin (assuming you are using the
status plugin).
Below is a diff for status.py. If you could give that a poke, that
would be useful. What that ought to do is tell the browser to go back
to the server to ask for /status again, each time. It may not though,
as caching never seems to work like one expects.
> context.serverStatus.username gets set. I started tracing it back, but
> I became cross eyed and fell out of my chair. I think it comes from
> userParams but I'm not too sure.
Javascript makes me fall out of my chair too.
> * Reopen the wiki from the same recipe and look at the same tiddler as
> before. The tiddler still shows only a view link even though you're
> now logged in as User2 with write access on the bag.
> * Clear the cache, reload the page, and view the same tiddler. Now the
> tiddler will show the edit link as it should.
You seem to have correctly interpreted what's going on here. The
browser is caching the wiki with an ETag. When the second user loads
the wiki the browser validates the ETag against the server and the
server says, "yah, we still got the same ETag, you go ahead and use
what you've got cached".
However the content shouldn't be considered the same because of the
change in the server.perms attribute on the tiddlers that ought to be
there.
I can think of a few ways around this in various combinations:
* Include the current user in the ETag generation routines.
* Always use lazy loading when retrieving tiddlers (so we cache the
wiki framework but not the tiddlers themselves)
* Turn off caching when tiddlyweb.user is not GUEST.
There's a sense to which the first one is probably a correct thing to
do, around line 60 in tiddlyweb/web/sendtiddlers.py
Thoughts?
> ...More stuff to come in due course.
I'm trembling.
diff --git a/status/status.py b/status/status.py
index 1248c54..f113571 100644
--- a/status/status.py
+++ b/status/status.py
@@ -6,6 +6,7 @@ def status(environ, start_response):
data = _gather_data(environ)
output = simplejson.dumps(data)
start_response('200 OK', [
+ ('Cache-Control', 'no-cache'),
('Content-Type', 'application/json')
])
return [output]
Oveek
laptop has been crashy).
On Aug 27, 5:42 pm, Chris Dent <chris.d...@gmail.com> wrote:
> This may be related to how IE is doing caching of requests back to /
> status from the TiddlyWebConfig plugin (assuming you are using the
> status plugin).
>
> Below is a diff for status.py. If you could give that a poke, that
> would be useful. What that ought to do is tell the browser to go back
> to the server to ask for /status again, each time. It may not though,
> as caching never seems to work like one expects.
The patch initially failed to apply because my copy of status.py was
indented by one less space for some reason. Also, even though the
patch was only one line I still managed to make a typo (omitted the
dash in 'no-cache') when I made the change manually, so when I first
tested yesterday it didn't work.
...anyway I can confirm that 'no-cache' does the trick and fixes the
issue with setting txtUserName.
> You seem to have correctly interpreted what's going on here. The
> browser is caching the wiki with an ETag. When the second user loads
> the wiki the browser validates the ETag against the server and the
> server says, "yah, we still got the same ETag, you go ahead and use
> what you've got cached".
didn't know what criteria the browser used to decide whether to use
cache or get a fresh copy. Your ETag explanation makes total sense.
With that in mind I used Wireshark to compare the HTTP headers from FF
and IE. Here's what I noted (this is pretty much a restatement of what
you described above, but I wanted to mention the difference in IE's
behavior):
* Open some_recipe/tiddlers.wiki.
* TiddlyWeb sends a response header with an ETag.
* Upon reloading:
** FF sends a GET request with an If-None-Match field containing the
ETag from the last tiddlyweb response.
** In contrast, IE sends a GET request without an If-None-Match field--
it makes no use of the ETag and therefore gets a fresh copy of the
page.
So the apparent conclusion that may by worth noting is FF saves ETags
when caching pages, but IE doesn't, leading to considerably less data
transfer in FF. Of course FF's caching brings to light the user
switching issue...
> However the content shouldn't be considered the same because of the
> change in the server.perms attribute on the tiddlers that ought to be
> there.
> I can think of a few ways around this in various combinations:
>
> * Include the current user in the ETag generation routines.
> * Always use lazy loading when retrieving tiddlers (so we cache the
> wiki framework but not the tiddlers themselves)
> * Turn off caching when tiddlyweb.user is not GUEST.
>
> There's a sense to which the first one is probably a correct thing to
> do, around line 60 in tiddlyweb/web/sendtiddlers.py
>
> Thoughts?
I like the lazy loading approach and definitely want to use it down
the road, but if the past brushes with LL are any indication I think
it's going to take more time to get it right. Also I think it would be
better to solve this problem without requiring people to use lazy
loading.
I'm finding the third option less appealing because I think we'd be
paying an unneccessary performance penalty by sacrificing caching,
especially given the alternative of going with option 1.
Chris Dent
On Aug 28, 2009, at 9:49 AM, Oveek wrote:
>> I can think of a few ways around this in various combinations:
>>
>> * Include the current user in the ETag generation routines.
>> * Always use lazy loading when retrieving tiddlers (so we cache the
>> wiki framework but not the tiddlers themselves)
>> * Turn off caching when tiddlyweb.user is not GUEST.
>>
>> There's a sense to which the first one is probably a correct thing to
>> do, around line 60 in tiddlyweb/web/sendtiddlers.py
>>
>> Thoughts?
>
> I agree, I think the first option is the correct thing to do.
As I was coding this up, I realized it was going to break some of the
caching optimizations that I've been experimenting with, such as the
cachinghoster plugin[1]. I think this indicates a problem in the
cachinghoster, not in this solution, but it does mean I'm going to
think about it for a while before committing.
I've checked the change in on a branch:
http://github.com/tiddlyweb/tiddlyweb/commit/1aebf5de49bf1314564adcdf6d48722844f8664d
[1] http://github.com/tiddlyweb/tiddlyweb-plugins/tree/master/cachinghoster
FND
I agree that this seems like the appropriate solution. (Even though it
seems a little hacky, as the same URI represents different views for
different users... )
> I've checked the change in on a branch
Am I right in assuming that only only tiddler collections' ETags are
affected by this change - i.e. individual tiddlers continue to use
"bag/title"?
If that's correct, no change should be required in the TiddlyWebAdaptor.
-- F.
chris...@gmail.com
> You seem to have correctly interpreted what's going on here. The
> browser is caching the wiki with an ETag. When the second user loads
> the wiki the browser validates the ETag against the server and the
> server says, "yah, we still got the same ETag, you go ahead and use
> what you've got cached".
>
> However the content shouldn't be considered the same because of the
> change in the server.perms attribute on the tiddlers that ought to be
> there.
>
> I can think of a few ways around this in various combinations:
>
> * Include the current user in the ETag generation routines.
required changes in cachinghoster (while relies on the Etags to add a
layer of static hosting) I could go ahead and release the "fixes" but
I've since come round to thinking that fixing it may not be the right
thing to do.
If, in fact, we do want the tiddlywikis that are generated by
TiddlyWeb to be cacheable, not just in browsers but also in
accelerator caches (squid and the like) then two things need to be
true:
* The common case for Etags of tiddler collections should be that the
Etags are the same, if it is the same list of tiddlers (bag id +
tiddler title), whatever the user may be.
* Tiddlywikis with identical Etags should have identical content.
This means that the server.perms attribute on tiddlers needs to go
away, as it is the thing which makes tiddlywikis different from user
to user.
That feature, though, does have a purpose: it provides a way for
plugin code to know if the tiddler is readable, writeable, deletable
by the current user.
Are there way to achieve the same feature without modifying the
TiddlyWiki that is initially delivered to the client?
Which feature is more important large-area web caching or simple way
to get at tiddler permissions?
FND
> TiddlyWiki that is initially delivered to the client?
The only way I can think of right now is on-demand loading - but that
would mean we'd have to write custom handlers for the relevant bits
(currently only toolbar commands) to accommodate the asynchronous nature
of such operations.
> Which feature is more important large-area web caching or simple way
> to get at tiddler permissions?
Well, if it really comes down to it, caching seems more important - if
only because the client-side could adapt.
However, the issue might be more complicated:
> the server.perms attribute [...] is the thing which makes tiddlywikis
> different from user to user
I don't think permissions are the only variable here; user bags (i.e.
"{{ user }}" in recipes) have the same effect.
Both of these factors undermine the notion of "the same URI will always
return the same content", which might be an issue that transcends the
TiddlyWebWiki vertical.
-- F.
Chris Dent
On Sep 17, 2009, at 6:50 AM, FND wrote:
>> the server.perms attribute [...] is the thing which makes tiddlywikis
>> different from user to user
>
> I don't think permissions are the only variable here; user bags (i.e.
> "{{ user }}" in recipes) have the same effect.
> Both of these factors undermine the notion of "the same URI will
> always
> return the same content", which might be an issue that transcends the
> TiddlyWebWiki vertical.
I should have been more explicit: "different from user to user when
the tiddlers involved are the same".
The context for this discussions is the situation where the ETag for a
list of tiddlers is the same between two documents, but the content of
the documents is different. That's bad because it causes the problem
Oveek saw when switching between users in the same browser.
When using user bags, the ETag will be different, even though the URI
is the same, because the ETag is generated from a hash of
bag_name:tiddler_title of all tiddlers in the collection of tiddlers.
"same URI will always return the same content" is a bit strict. The
idea is that the same URI will consistently return the same
representation, modulo various headers. So as '/' at twitter.com is
the current users home page, so too can /recipes/dyanuser/tiddlers be
a known thing that might have different content depending on the user.
FND
> the tiddlers involved are the same".
You're right, I hadn't taken that into account.
So I guess the conclusion is that the server.permissions field will be
removed from the wiki serialization?
I'm okay with that, but would prefer for this to be checked in on a
branch so I have time to adjust the client-side accordingly.
I don't think anybody else is making use of that field so far.
> "same URI will always return the same content" is a bit strict
Yes, I guess you're right - not sure what Roy would say though... (Not
that we had to be REST purists, of course.)
-- F.
FND
> removed from the wiki serialization?
We've agreed that's not required, for now.
It suffices to re-request the permissions on demand.
I've checked in an experimental plugin for this purpose:
http://trac.tiddlywiki.org/browser/Trunk/association/plugins/ServerSideToolbarCommands.js
Since this is largely untested and still has some rough edges, I have
not yet removed the permissions handling from TiddlyWebConfig.
A review of this approach would be most welcome.
Also, I don't like the name "ServerSideToolbarCommands", so alternative
suggestions would be great.
-- F.