Re: LYNX-DEV .asp pages

[David Woolley]

> 
> one of the sites we were using without any problems has changed their 
> login/password
> page, it is now being generated with asp code. since this change we can enter 
> the login and
> password, but after a valid submission, the next page fails to come across. 
> no error messages
> are generated.

Re-wrapped to standard lengths:

* one of the sites we were using without any problems has changed their
* login/password page, it is now being generated with asp code. since this
* change we can enter the login and password, but after a valid submission,
* the next page fails to come across. no error messages are generated.

From the browser point of view, anything that ASP can do can be done with
CGI, ISAPI etc., so we really need the actual site.
> 
> would lynx ver 2.7 corrected this problem ?

At a guess, this is because Cookie support is relatively new in Lynx and
ASP uses cookies to track session.  Chances are that it puts up the 
login page whenever it doesn't think there is an active session, and, if
you never return cookies, no session will ever be started.  2.7.1 definitely
supports cookies, and I think so does 2.7.

The right way to authenticate is with the HTTP authentication protocol, but
it almost certainly so much easier for Microsoft users to use the implicit
cookies from ASP and their own login form.  If a user name is only allowed
to be logged in once, HTTP authentication would give the same functionality
as cookies (ASP only stores the session ID in the cookie; the rest of the
state is stored on the server), but I get the impression that there is
no explicit support in ASP for using the user name as a key for the
state data, and that MS servers require that each user name be a local
machine user name (Unix servers separate web user names from local
user names).

(Lynx generates status line prompts for HTTP authentication, so it is
easy to recognize.)

If this site is forms intensive, there are alternatives to cookies.  If
it is readonly, HTTP authentication is much more efficient.  If state is
associated with a user, not a session, HTTP authentication is also more
efficient.

> would lynx ver 2.7 corrected this problem ?
                     ^^^^^^^^^
avoided would be a better word.  Lynx didn't cause the problem; even if
it is cookie related, the problem was that the site used a feature that
was not universally supported.  You might want to point out to them that
some sites are rumoured to have a "refuse all cookies" policy.
;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;