You are not logged in. Login Now
 0-24   5-29   30-49        
 
Author Message
20 new of 49 responses total.
devnull
response 30 of 49: Mark Unseen   Dec 22 17:18 UTC 1999

It would certainly be nice if it suddenly became the case that I chould
use kerberos telnet to log in to grex.  That functionality hasn't happened
yet.

As far as I know, web browsers don't yet have useful kerberos support.
MIT Athena has some mechanism for you to get a certificate for web use
which has a different password than your kerberos password.

However, some versoins of IE do support the NT4.0 challenge/response
authetnication scheme, and given that windows 00 is moving to kerberos,
I would be surprised if the version of IE that ships with 00 can't do kerberos
authentication.

If peoplre can't find any good auth scheme, they should just do something
that requires users to enter their password seprately for backtalk and party,
and go ahead and implement it, and worry about fixing it later if web browsers
start sucking less.
pfv
response 31 of 49: Mark Unseen   Dec 22 18:20 UTC 1999

        mod_auth_external works.. I'm using it.
        mod_cgisock works.. Using that as well.
remmers
response 32 of 49: Mark Unseen   Dec 22 23:22 UTC 1999

Re resp:29 - No, I can't.  I've just heard that they exist.
janc
response 33 of 49: Mark Unseen   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.
orinoco
response 34 of 49: Mark Unseen   Dec 25 18:21 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.  

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?
pfv
response 35 of 49: Mark Unseen   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.

gull
response 36 of 49: Mark Unseen   Dec 25 20:40 UTC 1999

If you can use a web browser, you can run telnet, too.  The idea is to save
people the bother of installing and figuring out a telnet client, I think.
pfv
response 37 of 49: Mark Unseen   Dec 25 22:55 UTC 1999

        With the quality of mentation seen lately? I'm *positive* it's 
        about lowering the curb even more.
gull
response 38 of 49: Mark Unseen   Dec 26 04:15 UTC 1999

Well, I've noticed that some of our more interesting and intelligent
conference participants aren't very computer literate, or at least weren't
when they started.  I don't think the ability to figure out how to telnet is
a good prediction of someone's overall intelligence.
pfv
response 39 of 49: Mark Unseen   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.
spooked
response 40 of 49: Mark Unseen   Dec 26 11:46 UTC 1999

You're right, Pete, but naive users feel more comfortable with a GUI, web
interface.
eeyore
response 41 of 49: Mark Unseen   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?
gull
response 42 of 49: Mark Unseen   Dec 26 18:13 UTC 1999

I assume they'd prevent that, since otherwise it'd be a handy way to get
around the telnet queue.
pfv
response 43 of 49: Mark Unseen   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.
orinoco
response 44 of 49: Mark Unseen   Dec 26 19:48 UTC 1999

It occurs to me also that if mail is one of the few things you can't get at
on the web, that'll help shift the balance away from people using grex just
for mail, which is something that we keep saying we should do.
pfv
response 45 of 49: Mark Unseen   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.
spooked
response 46 of 49: Mark Unseen   Dec 26 23:17 UTC 1999

Firstly, no, we won't be providing functionality to 'shell out to mail' from
the web.  Grex shouldn't be used primarily for e-mail.  There are a lot faster
and more suited sites for this.

It's not my aim to design web-party to draw in heaps of new users.  My
objective is to give existing party users, who use backtalk, and other
existing users the option of using web-party.  Once again, there are heaps
of sites dedicated to chat lines, who run more powerful processors.  We are
modernising, but not for the sake of removing ourselves from our principal
founding objectives - having party on the web, may also attract people to
backtalk.
orinoco
response 47 of 49: Mark Unseen   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.  
spooked
response 48 of 49: Mark Unseen   Dec 27 02:40 UTC 1999

Yup, they'll be very accessible from one another.
other
response 49 of 49: Mark Unseen   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.
 0-24   5-29   30-49        
Response Not Possible: You are Not Logged In
 

- Backtalk version 1.3.30 - Copyright 1996-2006, Jan Wolter and Steve Weiss