access to admin pages
i have a little concern about the ability to access administrative pages via the web without password confirmation.
there are a number of pieces of displayed information that could lead spammers to view these pages and figure out how to spam lists. for example, anyone can get access to whether a list accepts posts from anyone. anyone can gain access to specific anti-spam measures a list has configured, anyone can gain access to bounce control measures about a list and determine whether or what kind of out of service attack may be possible.
for all these reasons, and for the sake of the design of the administrative cgi script, it seems that it may be a good idea to stick the entire interface behind a single login and use cookies from there to allow access.
the reason this seems better from a design point of view of the admin script is that i recently spent a good deal of time adding a separate type of authentication to one section. it was quite complicated, as the script was designed for authentication only when changes were requested. as more different things develop under the administrative interface, some of them will require authentication for viewing and some won't. changing around the authentication scheme every time will involve work. it would be much simpler just to have one login at the onset and to cookies from there.
thoughts?
scott
"S" == Scott <scott@chronis.pobox.com> writes:
S> for all these reasons, and for the sake of the design of the
S> administrative cgi script, it seems that it may be a good idea
S> to stick the entire interface behind a single login and use
S> cookies from there to allow access.I agree!
On Fri, 24 Apr 1998, Scott wrote:
i have a little concern about the ability to access administrative pages via the web without password confirmation. [...] for all these reasons, and for the sake of the design of the administrative cgi script, it seems that it may be a good idea to stick the entire interface behind a single login and use cookies from there to allow access.
I have the same concern, and agree that the admin pages should be behind the admin password, instead of in front of it. I've already included a cookie mechanism (gotten from off the net), for the private archives which could be adapted to the purpose - though i think it should be refined a bit to reasonable timeout the cookies, which the mechanism supports...
[...] type of authentication to one section. it was quite complicated, as the script was designed for authentication only when changes were requested. as more different things develop under the administrative interface, some of them will require authentication for viewing and some won't. changing around the authentication scheme every time will involve work. it would be much simpler just to have one login at the onset and to cookies from there.
There actually is already a few styles for soliciting authentication info. In several places, the authentication information is required to accompany changes. For the private archives, when you visit one of those pages and lack a cookie with sufficient authentication info, you get an authentication soliciting page, and then proceed to the page you really wanted. I agree that the latter style is much nicer for many situations. I think password changes should still use the old style, but anywhere else the prompt could come up only when there's no cookie containing the authentication...
Ken
participants (3)
-
Barry A. Warsaw -
Ken Manheimer -
Scott