<<< Chronological Index >>>    <<< Thread Index >>>

Re: Access to RIPE-TT data from third parties


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 >>>