Subject: [Tools-discuss] loginmgr

From: Frank Ellermann <[email-masked]>
Date: Tue, 17 Oct 2006 09:49:31 +0200

Hi, the form to set a password has no "visible" submit button, but
that's required by Netscape 3.x and maybe similar HTML 3.2 browsers.
The <button> element (HTML 4) works to some degree with Lynx 2.8.5.

Maybe add... 
<input type="submit" value="set password" style="display: none" />
...or similar.  Or mybe an ordinary <input type="submit"> is also
okay for HTML 4 browsers, then you could get rid of the <button>.

For forms with one field it's no issue, they accept ENTER to submit.

The WDG bible says:

| However, BUTTON  is new in HTML 4.0 and poorly supported among
| current browsers, so INPUT is a more reliable choice at this time

Where "at this time" was some time shortly after December 1997... ;-)

Frank

_______________________________________________
Tools-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tools-discuss

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 17 Oct 2006 13:06:41 +0200

More about loginmgr and nominate.pyth:

Some browsers (like Netscape 3.x and 4.x) insist on Authorization: Basic,
that doesn't work for http://www1.tools.ietf.org/group/nomcom/06/nominate

In theory Authorization: Digest works (both RFC 2617 and RFC 2069 style),
but apparently it ends up on a "volunteer" instead of "nominate" page (?)

I can't use this in practice, it was a quick and dirty test using script
rxgeturl.cmd replacing its BASIC() by a DIGEST(), that's no Web browser.

With Lynx it fails completely - odd, maybe I just don't know how that's
supposed to work, normally Lynx is smarter than Netscape 4.x.

Frank

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 17 Oct 2006 13:40:13 +0200

Hi Frank

> supposed to work, normally Lynx is smarter than Netscape 4.x.

I'll check the lynx compatibility, and also check whether there's any
bad link pointing to 'volunteer', just in case.  Not going to change back
to basic http auth, though.

Regards,

	Henrik

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 18 Oct 2006 06:27:48 +0200

Henrik Levkowetz wrote:

>> normally Lynx is smarter than Netscape 4.x.

> I'll check the lynx compatibility, and also check whether there's
> any bad link pointing to 'volunteer', just in case.  Not going to
> change back to basic http auth, though.

That's a rather interesting issue from my POV:

- I never before saw a site supporting or even requiring auth digest.
  I'm happy that I could finally test a (wannabe) 2069 implementation
  resulting in a 200 OK from your side - my first hard evidence that
  a pending 2069-erratum might be okay.

- I'm not sure if limiting volunteers to "need a browser better than
  Netscape 4.x" is what you want, the public side of the datatracker
  AFAIK doesn't need this.

- For folks wanting just to use the "nominate" form it's in essence
  a mail generator (I think, as noted I arrived on a page claiming to
  be for volunteers).  Why should that be limited to browsers with
  auth digest ?  Maybe I'll send a nomination directly per mail as
  last year, or maybe I'll decide that it's a waste of time.

- If you like auth digest for some reason (as other folks who like
  cram-md5 ;-), technically it's not required on the https server,
  maybe you could offer auth basic over SSL for this "login" stuff,
  here for the purpose of inserting a verified From address in the
  generated mail to NomCom.

Frank

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 18 Oct 2006 11:07:11 +0200

Hi Frank,

> That's a rather interesting issue from my POV:

Before going into the items below, I maybe should have given more
information on why.  I do prefer digest auth, but the main reason
in this case is that there's no time to re-write the mechanisms to
handle login/password creation with email reachability verification,
with the NomCom site already having gone live, and there already
being ~140 people who have digest based login/password combinations.

>   a pending 2069-erratum might be okay.

Ok, this is not bad then ;-)

>   Netscape 4.x" is what you want, the public side of the datatracker

It wasn't the intention, but I realize now it's a consequence.
Especially since I've now tested lynx and checked up on its
capabilities, and it turns out that it seems to be the only major
browser (with a fairly inclusive meaning of major) which doesn't
support digest auth :-(

>   last year, or maybe I'll decide that it's a waste of time.

Sending nominations directly by mail is (and in my opinion should always
be) supported, and a note to that effect has been added to the entry
page of the nomcom-06 site.

>   generated mail to NomCom.

Yes.  I started the work on getting proper certificates some time ago,
but the ones which I almost received wouldn't have worked with both
the generic and specific tools server names (for instance both
www1.tools.ietf.org and tools.ietf.org) and I didn't have the time to
work out exactly what to request to accomplish that -- otherwise I'd
have run this over SSL.  Currently I only have a self-signed cert,
and that has proven to cause its own problems.

I'll get there, but I'm time-constrained ,;-)

	Henrik

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 18 Oct 2006 13:19:17 +0200

Henrik Levkowetz wrote:

> there's no time to re-write the mechanisms to handle login/password
> creation with email reachability verification,

That part works fine modulo one <button> ignored by hardcore HTML 3.2
browsers (we could decide that this is worldwide one user today... ;-)

What you've stored is probably MD5( user || ":IETF:" || password )

> I've now tested lynx and checked up on its capabilities, and it
> turns out that it seems to be the only major browser (with a fairly
> inclusive meaning of major) which doesn't support digest auth :-(

Odd.  I was also surprised that Netscape 4.x doesn't support this,
RFC 2069 was published 1997, and one of the authors wrote "Netscape"
in the organization field.

> Currently I only have a self-signed cert, and that has proven to
> cause its own problems.

If you're talking about <https://www1.tools.ietf.org/> - that works
perfectly from my (Netscape 3.x) POV.  Please don't try 2048 bits
for the password, then I'd get a "security library error" bogey :-(

Frank

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 18 Oct 2006 13:33:56 +0200

Hi Frank,

> What you've stored is probably MD5( user || ":IETF:" || password )

Right.  Well, actually the file holds

user ":IETF:" digest

where I assume digest is calculated as you show above.

> for the password, then I'd get a "security library error" bogey :-(

The problem isn't with the cert, it's with people's reaction when they
get a warning because the cert isn't signed by a known CA.

I don't think I should need 2048 bits yet, but we'll get there
eventually, I expect.

Regards,

	Henrik

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 21 Oct 2006 13:22:28 +0200

Henrik Levkowetz wrote:

> The problem isn't with the cert, it's with people's reaction when
> they get a warning because the cert isn't signed by a known CA.

After deleting several answers incompatible with RFC 1855 I jump to
a completely different observation:

rfcmarkup doesn't identify  <http://example.com>  as URL, without 
angle brackets it works.  I can see the "http link markup" comment
in your source, but after that I'm lost...  Apparently "<" and ">"
are already escaped at this point.

Frank

---

From: Henrik Levkowetz <[email-masked]>
Date: Sun, 22 Oct 2006 11:07:40 +0200

Hi Frank,

on 2006-10-21 13:22 Frank Ellermann said the following:
> After deleting several answers incompatible with RFC 1855

Hmm.  I frankly have no idea whether this is an observation which is
salitary, denigratory or neutral with respect to my observation above,
and I'm going to skip guessing.  If you want to elucidate slightly,
it might be good.

> I jump to

Yes, they would be.

I've changed this line (abbreviated):
   data = re.sub("(?im)(\s|^|[^=]\")(http://[:A-Za-z0-9_./%&?#~=-]+ ...
to this:
   data = re.sub("(?im)(\s|^|[^=]\"|&lt;)(http://[:A-Za-z0-9_./%&?#~=-]+ ...

(with similar changes in other places), which should fix this.

Regards,

	Henrik

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 22 Oct 2006 15:51:41 +0200

Henrik Levkowetz wrote:

> If you want to elucidate slightly, it might be good.

Folks trusting arbitrary CAs as shipped with their UA, but not trusting
that http://tools.ietf.org really is https://tools.ietf.org only because
it uses a self-signed certificate, might be "confused" (my first deleted
reaction was stronger... ;-)

>    data = re.sub("(?im)(\s|^|[^=]\"|&lt;)(http://[:A-Za-z0-9_./%&?#~=-]+ ...

Thanks, but apparently it doesn't work yet (?)  The <http://example> format
is used by "external reference" elements in xml2rfc.  For a multi-line case
see RFC 3986 appendix C near http://tools.ietf.org/html/rfc3986#page-52

http://tools.ietf.org/html/draft-ellermann-spf-options-00#section-4 contains
the single-line case <http://xml.resource.org>  It could be some cache issue.

Maybe replace http by (f|ht)tp or similar to catch also ftp-URLs when / if
you look at it again, ftp-URLs are quite common.

Frank

---

From: Henrik Levkowetz <[email-masked]>
Date: Sun, 22 Oct 2006 16:56:08 +0200

Hi Frank,

> reaction was stronger... ;-)

Yes, certainly.  Agreed.

> see RFC 3986 appendix C near http://tools.ietf.org/html/rfc3986#page-52

Ah, but I need to flush the cache, too :-)  I'll grep for all RFCs/drafts
with "<http://" later today and remove them so they can be re-generated.

> the single-line case <http://xml.resource.org>  It could be some cache issue.

Heh.  I wrote the text above before I read this paragraph.  Quite right.

> you look at it again, ftp-URLs are quite common.

Ok, will have a look at that too.

	Henrik

---

From: Henrik Levkowetz <[email-masked]>
Date: Sun, 22 Oct 2006 17:22:22 +0200

Follow-up:

on 2006-10-22 16:56 Henrik Levkowetz said the following:
...
> with "<http://" later today and remove them so they can be re-generated.

Cache flushed and the multi-line case tested.  It turns out that in the
case of URLs enclosed in "<" ... ">" I can handle the multi-line case better
than for URLs not so enclosed, so I changed the code a bit to do that.  Also
included handling of ftp:// URLs.  The example above should be handled well
now.

	Henrik