response 25 of 49:

Dec 20 21:01 UTC 1999

        "keatings of text"

        Janc? Why can't a web-party use the same methods as BackTalk?
        (I still have to wonder where the session-ID stuff is sent
        back and stored)

response 27 of 49:

Dec 21 11:51 UTC 1999

There exist Java telnet applets, maybe even free ones.  Would it be
feasible to hack one those so that a user who logs in through it
doesn't go into the telnet queue and would be put in a special shell
rather than their normal shell?  The special shell could be a
restricted version of party that doesn't allow shell escapes.  This
would be a quick and dirty way of providing web-based party that
wouldn't require an elaborate "party server" to be written.

response 29 of 49:

Dec 22 01:11 UTC 1999

John, could you point me to one of these telent applets please?

response 31 of 49:

Dec 22 18:20 UTC 1999

        mod_auth_external works.. I'm using it.
        mod_cgisock works.. Using that as well.

response 33 of 49:

Dec 25 03:21 UTC 1999

Re Java telnet:  This one looks good:

  http://www.first.gmd.de/persons/leo/java/Telnet

I've been thinking of installing that on Grex, so people who can't
manage to set up a telnet connection can just click a button on a web
screen, have this applet load into their browser, and connect them to
Grex.  I haven't experimented with it enough to decide if it would work
well.

Re authentication:  Let's see what happens if we use Backtalk style
authentication with a party Java applet:
  (1) User follows a link or bookmark to the "Grex Party Page".
  (2) Before he can access the page, a login box pops up.  He must enter
      a valid Grex login and password before the page will load.
  (3) After the user logs in, the page with the embedded Java applet is
      sent to his machine.  The browser executes the Java applet.
  (4) The applet opens a network connection to the party port on Grex,
      which puts it into communications with a party server there, so
      the user is now in party.
Does that look OK?  It shouldn't.  Suppose instead:
  (1) The user finds or writes his own party client program, in Java or
      some other language.
  (2) He runs the program, which connects to the party port on Grex, so
      he is in party.
So we've just bypassed the supposed security and connected to party
without logging in.  Note that in the first scenario there were two
quite separate transactions - first download the Java party client via
HTTP, then make a persistant TCP connection to the party server, so we
can send and receive lines of party text.  If we authenticate only the
HTTP transaction, then all we are doing is limiting access to our copy
of the party client, we are NOT limiting access to party.  To be secure,
the authentication has to be done when the persistant TCP connection is
made to the party server.  Since it isn't the HTTP connection that we
what to authentication in this instance, no HTTP authentication system
is useful.

I suppose you could implement it so that the second connection is done
via HTTP.  If you can write the Java applet so that it communicates with
the party server using browser's implmentation of HTTP, then you might
be able to avoid the login-twice problem (it would be useless to just
implement your own HTTP client within the Java applet because it
wouldn't have access to the browser's cache of login/password pairs and
so wouldn't avoid the double-login problem).  However, from what I hear,
under Netscape Java applets have only very limited access to the
browser's HTTP interface.  You can cause a page to be fetched by the
browser, but the page content can't be passed back to the Java applet. 
It has to go into a browser screen (though possibly an invisible one). 
Once in a screen, the Java applet can access only the values of boxes in
forms on the page, not the full text of the page.  You could live with
passing all party lines to the Java applet as values of boxes in a form,
but you still have to deal with the fact that HTTP normally doesn't do
continuous connections - it just sends a block of data and disconnects. 
Either you have to get into one of the odd continuous HTTP variants
(which I don't know much about and the devil only knows what the Java
interface to those is like), or you have to poll for new lines to party,
which generates *lots* of network and cpu overhead on Grex.  Plus you've
now introduced so many browser dependencies that you'll have to write
two different versions, one for Netscape and one for IE.  In summary, I
think this could be done, but it would be amazingly evil.  If that's the
only solution, I'd rather login twice.

response 35 of 49:

Dec 25 19:41 UTC 1999

>I didn't realize it was possible to have a connection that would let you
>use a web browster with Java (not just lynx or something) and still not be
>able to use telnet.

        Near as I can tell, java is your run-of-the-mill 'language', with
        limitations about what it can access on your system, sockets
        themselves are prolly trivial - ports more so.

>And about the login-twice bit....couldn't you just switch steps (2) and
>(3)? If you needed to use a password to use the party client anyway, why
>should we still require you to use a password to download it also?

        I think he's talking strictly about .htaccess topics. However, if
        the download was "passworded", I'd expect the download to 'know'
        the password and port to which it should be talking from then on.

response 37 of 49:

Dec 25 22:55 UTC 1999

        With the quality of mentation seen lately? I'm *positive* it's 
        about lowering the curb even more.

response 39 of 49:

Dec 26 06:54 UTC 1999

        Perhaps not, but.. It's not like it's rocket-science.

        Having just set up some newbies this month, I was interested to
        note they simply saw the win-telnet window, asked what it was, and
        went back to the web.

        My own father, during one visit, looked over my shoulder and said
        "OH, you are using AOL." <Umm, no Dad - I'm telnetting into Ann
        Arbor on grex.> Off he wandered, eyes glazed.

        I'll say it again: making anything "web-accessible" doesn't mean
        an improvement, better, or anything other than some glitz.

response 41 of 49:

Dec 26 14:47 UTC 1999

Out ouf curiousity, once you hit into the web-party connection, will you be
able to shell out into mail and such, like in normal party?

response 43 of 49:

Dec 26 18:46 UTC 1999

        I believe the idea was to reach "party" and "telegrams" webside.

        For most of us, between Backtalk and those two, we're all but
        covered.

response 45 of 49:

Dec 26 20:01 UTC 1999

        Amen, brother..

        I'm not going to play at Chicken-Little, but I'm not all that
        excited over "weberizing" the world.. The idea of hundreds of
        bored and inane surf-monkeys converging on party as a "chat site"
        is no more amusing then the dufii that keep trying to compile
        their network and IRC toys - or downloading their porn and doing
        whatever it is beyond getting their keyboards sticky.

response 47 of 49:

Dec 27 01:02 UTC 1999

Actually, if party and the bbs both were on the web, it might be good to have
a link somewhere on the web party page to the backtalk page, and maybe a
short sentence telling you what it'll be.  

response 49 of 49:

Dec 27 17:14 UTC 1999

the link could even bring them up in separate windows, so that those
interested will not lose threads in either in order to check out the other.