Re: LYNX-DEV WebStar Server with DynaMorph problems

[Klaus Weide]

On Sat, 1 Nov 1997, Doug Kaufman wrote:

> I have found a site that I would like to access with lynx, but can't get a
> display of the pages.  I was hoping that someone was familiar with this
> problem and can give me a hint on how to do it.  The site uses a WebSTAR
> server with DynaMorph enabled.  On Netscape the display looks like a frame
> display, but with no line between the frames.  Using a DOS version of lynx
> (ac-0.87, compiled with PDCurses 2.3) or a Unix version (SUNOS 4.1.3_U1,
> compiled with SLANG, Fotemods from September 5, 1997), I only get a blank
> screen when going to the pages indicated by any of the links in the
> style "query.morph?nameofpage".  Following is a "Print" of the side
> frame having the links to the pages that I was trying to reach, followed
> by a trace from the DOS version.  (If anyone wants to try this site, you
> will have to register.  They don't seem to send out UCE, however.) I
> sent this with the long lines unmodified; I hope they get through any
> intermediate sites in readable condition.
> 
> The "TrackID" changes with each visit to the site.
> 
> 
>                                   SIDE_NAVmap
>                                        
> MAP: 
> http://www.cjp.com/blood/html/sidemenu.morph?ForceTrackID=tid10286#SIDE_NA
> Vmap
> 
>      * [1]http://www.cjp.com/blood/logout.morph?TrackID=tid10286
>      * [2]http://www.cjp.com/blood/query.morph?nameofpage=watch1.morph&Fo
>        rceTrackID=tid10286
>      * [3]http://www.cjp.com/blood/query.morph?nameofpage=journal1.morph&;
>        ForceTrackID=tid10286
>      * [4]http://www.cjp.com/blood/query.morph?nameofpage=reviews1.morph&;
>        ForceTrackID=tid10286
[ etc. ]

Those links, which Lynx creates from a MAP element's content, are
supposed to return a 302 redirection to the "real" location when
activated.  Experimentation shows that they don't do that, but just
return an empty 200 response, if the request does not include a
Referer header filed with (at least) the string
morph?ForceTrackID=tid<NNNNN>.

Previous versions of Lynx would send

Referer: 
LYNXIMGMAP:http://www.cjp.com/blood/html/sidemenu.morph?ForceTrackID=tid10286#SIDE_NAVmap

in this situation.  That isn't really an official and valid URL, but
what Lynx uses internally to identify the resource it generates
internally for the HREFs from a MAP.  It happens that it contains the
string the server is looking for, so the server would send the 302
redirection and things would work.

This is why later versions of the Lynx development code (and 2.7.1f)
act differently now:

1997-07-02
  ...
* Mods in LYGetFile.c to include URLs with content from a form submission
  with method GET in the group for which Referer headers are never sent,
  because the content might include private (e.g., password or credit
  card) information which should not be visible in Referer logs. - FM

So it appears we have a conflict of interest here, since I FM's concern
is a valid one.

Anyway, the code doing this additional check is

                    if ((LYNoRefererHeader == FALSE &&
                         LYNoRefererForThis == FALSE) &&
                        (url_type == HTTP_URL_TYPE ||
                         url_type == HTTPS_URL_TYPE) &&
                        (cp = strchr(HTLoadedDocumentURL(), '?')) != NULL &&
                        strchr(cp, '=') != NULL) {
                        /*
                         *  Don't send a Referer header if the URL is
                         *  the reply from a form with method GET, in
                         *  case the content has personal data (e.g.,
                         *  a password or credit card number) which
                         *  would become visible in logs. - FM
                         */
                        LYNoRefererForThis = TRUE;
                    }

You may want to disable this and see whether this really solves the
immediate problem.

I question whether the server's behavior is a good idea, since the
content of the Referer header line is something that can be faked
easily (as I did for testing), so this doesn't afford any protection.
In fact the tracking system can be easily fooled; the tracking IDs are
assigned sequentially, so it is simple to guess a valid one that has
been assigned to someone else and then use that for requests that
would be tracked as being part of the other user's session.  Some of
the pages also use HTTP cookies, my remark may not apply to those.
But, if the service has to be session-based, then why not used HTTP
cookies exclusively, which exist explicitly for this purpose.



    Klaus

;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;