Re: New archives for testing

On Mon, Dec 31, 2012 at 11:47 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Magnus Hagander <magnus(at)hagander(dot)net> writes:
>> On Sun, Dec 30, 2012 at 9:53 PM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
>>> I don't think it was originally intended as a prompt (it's the security
>>> realm actually), but most browsers showed it anyway and it's been (ab)used
>>> that way for years. FYI, the browser I saw not displaying it was Safari on
>>> iOS, so most definitely not 'little used'.
>
>> No, but not showing it makes it a pretty useless browser since it's
>> supposed to tell the user which password to use when different
>> sections on a site has different passwords.
>> ...
>> So the question is how much effort we want to put into it. If we make
>> the 401 page itself contain the text, does that show up in safari
>> after authentication has failed, or does it show some custom page?
>
> At least on iOS 6, Safari doesn't seem to show any 401 page at all.
> When you hit the "raw" link, you get an "Authentication required"
> popup with just space for username and password. If you put in
> a wrong value, the popup re-appears. There's not much you can
> do except hit "Cancel". Not very helpful at all I'd say. (Now
> admittedly, on a phone-size screen it's not clear that there's
> room for much of a prompt, but still...)

Well, the page usually shows up once you hit cancel. It's not very
user friendly, but that page is at least in theory customizable. But I
think a lot of browsers don't show it.

There is plenty of room on the phone screen to do a prompt. At least
android has no problem at all with it. But that doesn't really matter
if a platform that's half of our mobile visitors can't handle it -
because we can't change that. Unless we want to take the same approach
as we do with some of the windows code, which is say "it's good
enough, if people want the better functionality they should pick a
more suitable platform". (which for the access of raw or mbox isn't
entirely unreasonable, really..)

> Having just done the experiment, though, I'd have to say that the
> usability of the archives is pretty darn low regardless of this.
> Too many very small links too close together --- there's basically
> no way to hit what you want accurately without zooming way in first.

I guess I'm spoiled by a browser that auto-zooms just the links when
you accidentally click next to another one, making that a non-issue.
But probably more useful, we could do with a mobile adapted version
*period*. The whole site, where the archives inherits the style, works
fairly badly on small screens (and really big ones, it only really
works well for medium sized ones).

But is it actually any worse than the old archives? Because they work
pretty bad in mobile as well, don't they? Personally, I find them even
harder since the text of the emails tends to be smaller in comparison
to the header... And if it's not a regression against the new ones, I
think it needs to go on the TODO list rather than being a blocker..

> (And that was on an iPad; don't even want to think about a phone.)
> I can't see anybody really caring about either the mbox or raw links
> in that context.
>
> But on the third hand ... could we rig it to accept any old name and
> password? The mere occurrence of a challenge ought to be enough to
> discourage most bots.

Not easily. We could for the raw links, because that authentication
prompt comes from our app. But the mboxes are served directly by the
webserver, which has a fixed password list. So we'd have to write our
own auth module to do that, which is a piece of work I don't think we
want to take on.

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/