<<<
Chronological Index
>>> <<<
Thread Index
>>>
Re: Access to RIPE-TT data from third parties
- To: ttm@ripe.net
- Subject: Re: Access to RIPE-TT data from third parties
- From: Ana Susanj <ana@ripe.net>
- Date: Thu, 11 Jan 2001 13:40:53 +0100
- In-Reply-To: <Pine.BSI.4.05L.10012221354140.17664-100000@x49.ripe.net>; from henk@ripe.net on Fri, Dec 22, 2000 at 02:00:58PM +0100
- References: <20001221224949.A8947@ripe.net> <Pine.BSI.4.05L.10012221354140.17664-100000@x49.ripe.net>
- User-Agent: Mutt/1.2.5i
hi hi,
There's one more function to make better (chpasswd) but the rest
seems functional to me so ..
Could all or some of you go have a look at what I've done so far
and tell me all the problems that you can see with the user
interface design, so that I can start fixing those when I finish
with the passwd thing? Also, any other changes that might be needed..
Other design ideas?
url: http://fruit.shallow.net/tt/
usernames: marks, fotis, rene, henk, daniel
passwords: testing
all these usernames have admin access to one box and read rights to
usually all three boxes.
there's also username: ripe
with password either: ripe or testing (i forget :)
ripe username has admin access on all three boxes.
PS there is a little 'feature' ;) that should be gone but doesn't
do any harm: if you go to modify, you might see some users listed
more than once, the number of times listed seems to equal to the
number of admin groups that they are a member of.. I haven't looked
further into this.
ana.
>
> > Elo.
> >
> > > From our side, there is one other requirement: the scheme
> > > must still be
> > > maintainable, we do not want to spend our days adding and resetting
> > > passwords. Ana, our new network engineer, is currently looking at the
> > > best way to implement this.
> >
> > OK. I met with Mal this afternoon to see what he's done about a similar
> > thing (secure web stuff where LIRs can log in and add new contacts etc..).
> > We'd have a bit more to keep in mind than he does as there are those
> > ttxy directories.
>
> OK, so if I understand this correctly, there are 2 groups for each
> test-box: ttxx and ttxx_admin. ttxx_admin can add/delete user/password
> combinations. ttxx can only look. This looks like what we want.
>
> > He's done something very similar. The only difference being that he's
> > storing crypt passwords in plain text files, which is not as efficient
> > in perl (as storing them in dbm files) (code efficient).
> >
> > Another thing he suggested was to put all functions into one file (e.g.
> > add, modify, delete) rather than having them separately. But I originally
> > had that in mind anyway. It just means less duplicated code.
>
> You can also put the common code in a perl-module and load that in the
> scripts. The functions are then still separate (and thus more
> maintainable), but no code is duplicated.
>
> > This seems sufficient, but I'm open for criticism and comments. Does
> > anyone have any or should we give this a go?
>
> We need the delete.cgi.
>
> Perhaps you can combine add.cgi and modify.cgi (if a user exists, then
> modify his permissions, if not, make a new one).
>
> Other than that: yes, let's try this.
>
> Henk
>
>
> ------------------------------------------------------------------------------
> Henk Uijterwaal Email: henk.uijterwaal@ripe.net
> RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk
> Singel 258 Phone: +31.20.535-4414, Fax -4445
> 1016 AB Amsterdam Home: +31.20.4195305
> The Netherlands Mobile: +31.6.55861746
> ------------------------------------------------------------------------------
>
> A man can take a train and never reach his destination.
> (Kerouac, well before RFC2780).
>
--
~
~ Oh hello, Mr. Soul, I dropped by to pick up a reason;
~ NY
<<<
Chronological Index
>>> <<<
Thread Index
>>>