Question about Thumbnail plugin and cookies/credentials

8 views
Skip to first unread message

Jim

unread,
Mar 16, 2009, 10:41:01 AM3/16/09
to fluidapp
I was configuring the thumbnail plugin to show me thumbnails for a
particular set of links in a web app I work on. This led to a few
questions/observations:

1) A curiosity: I had to write a userscript to modify all of the URLs
I wanted to thumbnail so as to add the protocol and host to them. Any
URL the plugin attempted to work with was simply being prepended with
http:// if it was relative, rather than using the protocol/host of the
page in question.

2) A problem: the pages I wanted to thumbnail require that a user be
logged in. Although I had logged into the website via the SSB, the
thumbnail browser apparently did not have access to the cookies for
the site in question because all of the thumbnails came back with the
login screen we would show to someone who requested the page without
being logged on.

Can anyone shed some light on any of this and how I can work around
it? Are these bugs?

Thanks so very much!
Jim

Todd Ditchendorf

unread,
Mar 16, 2009, 2:05:34 PM3/16/09
to flui...@googlegroups.com
On Mon, Mar 16, 2009 at 7:41 AM, Jim <auldr...@gmail.com> wrote:

I was configuring the thumbnail plugin to show me thumbnails for a
particular set of links in a web app I work on.  This led to a few
questions/observations:

1) A curiosity: I had to write a userscript to modify all of the URLs
I wanted to thumbnail so as to add the protocol and host to them.  Any
URL the plugin attempted to work with was simply being prepended with
http:// if it was relative, rather than using the protocol/host of the
page in question.

that sounds like a bug. but at least the workaround is easy :|
 


2) A problem: the pages I wanted to thumbnail require that a user be
logged in.  Although I had logged into the website via the SSB, the
thumbnail browser apparently did not have access to the cookies for
the site in question because all of the thumbnails came back with the
login screen we would show to someone who requested the page without
being logged on.

i realize this can sometimes suck, but this is intentional, and if you think about it, the alternative would suck worse.

if the thumbnail plugin shared cookies with the main SSB webviews, you'd pick up *a lot* of extra, unwanted cookies whenever you used the plugin with say, google, digg or pretty much any other site.

when u use webkit in your app (like fluid and the thumbnail plugin do) you have three cookie-handling behavior options (look under the Security Prefs Pane to see these). So for the thumbnail plugin, the cookie-handling preference is always 'accept no cookies' to avoid cluttering your cookie jar (which is shared with Safari and other Fluid SSBs) with tons of junk cookies.

as has been often discussed here, webkit (by default) does not offer the ability to partition cookie jars (this is why all fluid ssbs share cookies with safari, etc), so it's not possible for me to just tell the thumbnail plugin to use a separate cookie jar (without going to extreme lengths of developing my own custom webkit or adhoc cookie jar solution, which I am not willing to do).

the only possible change to this i might make is to add an "Accept Cookies" preference to the Thumbnail plugin pref pane -- that would allow it to pollute your shared cookie jar with cookies from the pages viewed in thumbnails if you wished.

But honestly, i dont think most users would understand the implications of this, and when it comes to features involving cookies, I definitely tend to err on the side of caution.

Maybe i could add a user default -- so expert users could change that setting on the command line?

td

Jim Auldridge

unread,
Mar 16, 2009, 2:22:21 PM3/16/09
to flui...@googlegroups.com
Todd,

I know what you're saying with the thumbnail browser, and don't take
issue with it.

I just wanted to make sure that what I was seeing was accurate and
intended. Not sure what would be best in that area as I'd have loved
to show this content in the thumbnail browser but I fully understand
the implications.

Thanks for an awesome product and for weighing in on my questions.

Cheers,
Jim
--
Jim Auldridge
11012 Lincoln Ave
Hagerstown MD 21740
301.582.9050 (h)
240.520.0240 (m)
http://www.auldridges.com

Religion that is pure and undefiled before God, the Father, is this:
to visit orphans and widows in their affliction, and to keep oneself
unstained from the world.
--James 1:27 (ESV)

Jim

unread,
Mar 17, 2009, 7:55:57 PM3/17/09
to fluidapp
Todd,

One more thought on this matter...is it possible to give the thumbnail
browser read only access to cookies already set for the domain of the
page being thumbnailed? If so, I believe that would be ideal.

Thanks,
Jim

On Mar 16, 2:05 pm, Todd Ditchendorf <todd.ditchend...@gmail.com>
wrote:

itod

unread,
Mar 17, 2009, 10:10:13 PM3/17/09
to fluidapp


On Mar 17, 4:55 pm, Jim <auldrid...@gmail.com> wrote:
> One more thought on this matter...is it possible to give the thumbnail
> browser read only access to cookies already set for the domain of the
> page being thumbnailed?  If so, I believe that would be ideal.
>

not sure if it's better to call this 'write-only' or 'read-only'
access... but you are wanting webkit to *send* the cookies from the
shared cookie jar, but not accept any new cookies into the jar.

hmm, let's see. there are three cookie-handling behavior options
exposed by WebKit:

Accept Cookies:
- Always
- Never
- Only from sites you browse to

for the Thumbnail plugin's offscreen webviews which render the
thubnails, I have set this to 'Never' and have not provided any option/
UI for users to change that.

honestly, i dont know what effect this has on the cookies sent to the
server (although you could sniff with an app like HTTPScoop.app and
find out). i will try to test that soon.

also note that the offscreen webviews used by the thumbnail plugin to
render thumbnails has JavaScript turned off. Long story, but trust me,
it's *much* better that way.

td

jedediah

unread,
Mar 25, 2009, 12:36:47 PM3/25/09
to fluidapp
"Maybe i could add a user default -- so expert users could change
that
setting on the command line? "

I'd love to see this feature; it would help for some password
protected sites that I use on a regular basis.

-j
Reply all
Reply to author
Forward
0 new messages