On Jul 28, 2005, at 5:33 PM, Trejkaz wrote:
> I guess the only benefit of doing it this way is that the page is
> the same for
> all users (so the cache can be used for the admin users as well.)
> But in
> reality, the admin users are the tiny minority, so caching wouldn't
> really help
> that much.
>
> I agree... it should work server-side so that admin elements are
> only put in the
> HTML if the user is an admin in the first place. It doesn't
> actually seem
> useful to have an "is_admin" cookie when the server already knows
> the user is
> an admin.
>
> To divert a bit, I also think that this show/hide script is
> something which CSS
> can do...
>
> #admin_article { display: none; }
> div.post:hover #admin_article { display: block; /* or whatever */ }
>
> ...but I understand that when you have a hammer (JavaScript),
> everything starts
> to look like a nail. :-)
Not exactly. The problem is that once we cache a page, Apache never
calls us again for that page[1]. We can't check for admin status
because we don't even run--Apache (or whoever) serves the static HTML
directly to the client. If we want to do the admin check on the
server end then we have to completely stop using Rails's page cache,
and that's a massive performance hit for all users, not just admins.
Putting the admin URL in the page and doing the admin check on the
client side seems like a low-cost way around this. The admin URL
isn't leaking any information--all Typo blogs put it in the same
place, and the article ID shows up other places in the same file.
The admin pages need a login to work, so there's really no security
issue.
Scott
[1] Until it's swept from the cache due to some other action, that is.
From trejkaz at trypticon.org Thu Jul 28 21:32:36 2005
From: trejkaz at trypticon.org (Trejkaz)
Date: Thu Jul 28 21:27:37 2005
Subject: [typo] typo admin shows up on google.
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
Quoting Scott Laird <[EMAIL PROTECTED]>:
> Not exactly. The problem is that once we cache a page, Apache never
> calls us again for that page[1]. We can't check for admin status
> because we don't even run--Apache (or whoever) serves the static HTML
> directly to the client.
OK. I was under the impression that the cache was implemented on the Rails
side, in the same fashion that people write page caches in Java on the Servlet
side.
> If we want to do the admin check on the server end then we have to completely
> stop using Rails's page cache, and that's a massive performance hit for all
> users, not just admins.
Actually, I'm starting to wonder why Apache doesn't do this caching instead of
needing to implement it manually on the Rails side. Really, a webapp should
only have to put the right cache headers on the pages it returns, and
the thing
serving that page should be the one to decide how it's cached. Otherwise
everyone implements it separately (which is what we're witnessing here.) :-/
I guess a lot of people throw a Squid in front of their server for
exactly that
reason, though... so that they can get caching on anything without writing any
code.
> Putting the admin URL in the page and doing the admin check on the
> client side seems like a low-cost way around this. The admin URL
> isn't leaking any information--
--except the fact that there is an admin interface at all.
Good security practice is to not show things that users don't need to
know, and
good bandwidth-saving practice for is to not serve things that users
will never
get to see.
I suppose if the admin markup were served using AJAX calls which were
initiated
only for admins, that would solve both issues.
TX
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
