next message in archive
next message in thread
previous message in archive
previous message in thread
Index of Subjects
Index of Subjects > Hi Kevin... am I correct in assuming that although this visitor account > will not be accesible from a telnet connection... you will still have a > "guest" account that will allow a telnet session to apply for an account > and explore public portions of the community network...? Yes. The guest login will remain in place as before and as you described. > Alternatively...I wondering if we should give some thought to the > name of such an account... it would be helpfull for travellers if the > "visitor" account had the same name across partner systems. With the > comming of bilingual service we have now use "visiteur" as our French > "guest" account. Does this suggest a need to have four guest accounts? > > guest/visiteur > visitor/??? I see the problem. However, I know very little French; therefore, I'll have to ask others for suggestions on this one.... Thanks for your reply. Kevin Traas Hardware/Software Committee Chairperson FVCIS / ValleyNet Chilliwack, BC, Canada > david potter > > On Tue, 24 Jun 1997, Kevin Traas wrote: > > > Date: Tue, 24 Jun 1997 14:20:24 -0300 > > From: Kevin Traas <ktraas@uniserve.com> > > To: csuite-dev@chebucto.ns.ca, "Matthew R. Brown" <m_brown@uniserve.com> > > Cc: hscom@valleynet.bc.ca > > Subject: Re: Visitor's Telneting > > > > Just to add a comment regarding this feature (I'm the one who wrote it with > > input from several others). > > > > Right now, the user "visitor" is allowed to access our system either via > > dialup or telnet from elsewhere on the internet. However, access _to_ this > > account from the internet is for demonstration and/or evaluation purposes > > only and will be disabled in a "production" environment. > > > > Reasons for this include: > > > > 1. The whole point of having this "visitor" account is to allow visitors > > to our community to use our PATS (or otherwise) to dial into our system and > > then access their "home" system for e-mail, etc. i.e. These visitors will > > only be using our local dial-up numbers. > > > > 2. Allowing someone to connect to a system and then telnet elsewhere > > without having to enter a password (i.e. no user validation) is typically a > > bad idea. 'Net hackers use this method as an attempt to hide their trail > > (they bounce from system to system making it hard to find the originating > > connection). Therefore, incoming telnet connections should not be allowed > > to use the visitor account. (This is the reason guest isn't allowed access > > to telnet.) > > > > The package Matt is bringing to TC97 doesn't have any login restrictions; > > therefore, keep this in mind when/if you install it. The included README > > provides info on how to contact us to receive the "production" version with > > these restrictions in place. > > > > Matt Brown wrote: > > > > > I approached our tech staff and they came up with a simple but effective > > method for visitors to use our system to telnet back to their own community > > network. Here is how it works: > > > > > > - A visitor dials in with a terminal program to 702-1138. > > > > > > - Logs in as 'visitor' > > > > > > - Selects the community network from the menu list > > > > > > (the visitor is telnetted to that system) > > > > > > - Log in under your own name and password > > > > > > - when you log off your system you are logged off ours. > > > > > > Anyone wishing to have a peek can telnet into ValleyNet at > > > > > > 206.12.160.1 and login as visitor. > > > > > > I will be bringing this module to the CSuite Workshop at TC97.. > > >
next message in archive
next message in thread
previous message in archive
previous message in thread
Index of Subjects