Steve. You'll absolutly own that pizza.
impressive work arround about create managers in a record time. !!!!! congratulations!!!!.. where i could find that hack to dspam cgi's?. i really want to test that feature. thanks for your work my friend. Edgar On Fri, 11 Dec 2009 15:20:09 +0100, "Steve" <[email protected]> wrote: > -------- Original-Nachricht -------- >> Datum: Sat, 05 Dec 2009 16:49:37 +0000 >> Von: Paul Cockings <[email protected]> >> An: [email protected] >> Betreff: Re: [Dspam-devel] Control multiple users from one login on >> web-ui > >> I think flat file is absolutely okay (woof woof) >> LOL >> >> So if I really wanted this then maybe a 3rd file then called >> 'manager.cgi' that obeys a simple flat file? >> 'Managers' that need this function would use >> http://my-dspam-install/manager.cgi >> >> User A can control User 1,2,3,4 >> User B can control User 2,4,6,8 >> >> I suppose error handling would have to include missing (or misspelt) >> using, null user, missing file, corrupt file >> If 'manager' is not in 'flatfile' then user cannot login, they should go >> use http://my-dspam-install/users.cgi >> 'manager' can still login to http://my-dspam-install/users.cgi to >> control there own profile (but would only see their profile) >> >> I hear what you say about about this isn't best way and maybe during >> v4.0 brainstorming will can build this type of thing in... but until >> then a hack will work? Maybe as as a /contrib rather then main project? >> >> I am thinking simple ie 'manager' as the login user and can control xyz >> other users, no more, no less. >> >> Could I send you a pizza and a large packet of chocolate biscuits to >> code this up? I am lost in perl :-( >> > You own me a pizza! See the screen shots. > > I quickly wrapped the current DSPAM Web UI to be inside a layout created > with the Dojo (http://www.dojotoolkit.org/) toolkit. It took me 15 to 20 > minutes to do the initial wrapping. Including the effects of fading in like > in the Dojo Mail demo -> http://demos.dojotoolkit.org/demos/mail/ <- and > other small visual tricks. > > But then it took me more time to change the Perl code to cope with being > called from the new layout. I found some stupid errors that I have fixed as > well. Will push those changes to GIT as soon as I have time. > > The new admins (I call them "sub-admins") can administer users (depending > on the configuration) but can NOT go into the admin panel. > > I needed to create a second flat file (called "subadmins") that has the > following format: > <admin_user1>: <user1>, <user2>, <user3>, *@<domain1>, *@<domain2> > <admin_user2>: <user1>, <user2>, <user3> > <admin_user3>: *@<domain1> > <admin_user4>: *@<domain2> > > So one can say for example: > [email protected]: [email protected], [email protected], *[email protected] > > That would allow me to manage [email protected], [email protected] and every > user being in the gmx.net domain. > > That domain management thing was not that easy to do. I had to take extra > steps to not invalidate the DSPAM security by allowing domains to be > managed. Was tricky but obviously I solved it :) > > I needed to change the templates as well. I don't need their header and > other stuff so I just removed it. They are now smaller (no menu, no header, > etc, just the body). I could have left that and strip the header or just > use the body from within Dojo but why leaving something in place that > anyway is not needed? > > So with some small time investment I have made a brand new look and feel of > the current DSPAM Web UI and extended it's functionality. It feels now much > more modern. > > I have used Google ajax api CDN to reference Dojo. So the whole Web UI is > now dependent on it. I could however use a local copy of Dojo without > issues. > > I have NOT replaced Perl. It's still Perl and NOT PHP. Changing everything > to PHP would have been possible but if memory does not fool me then others > here in the community have said to produce a PHP Web UI and I really only > wanted quickly to make something that works and not change the whole > technique behind the Web UI. > > ** Me STILL waiting for that PHP Web UI that others have promised ** > > So what do you guys think of the Web UI? From the functionality viewpoint > it is the same Web UI as the old one (with just a bunch of fixes but they > will soon be in stock DSPAM as well). > > >> Pc >> > Steve > > >> >> >> Steve wrote: >> > -------- Original-Nachricht -------- >> > >> >> Datum: Sat, 05 Dec 2009 15:44:28 +0000 >> >> Von: Paul Cockings <[email protected]> >> >> An: [email protected] >> >> Betreff: [Dspam-devel] Control multiple users from one login on web-ui >> >> >> > >> > >> >> I have some customers that have multiple address's being filtered by >> the >> >> same Dspam server. To check each account (they are separate as far as >> >> >> >> Dspam is concerned) the end user has to log in as user 1, check >> account, >> >> close browser, log in as user 2, check account, close browser... >> >> /loop/ >> >> >> >> Is they anything we can easily do to change the web-ui to handle one >> >> user login that can 'manage' several accounts? Note, I don't want >> >> shared/merged groups as these accounts are better left as individual >> >> spam databases. >> >> >> >> >> > Currently you can't switch users. Only an administrator can do that. I >> guess declaring them as administrators on DSPAM WebUI is not an option? >> > >> > The WebUI works that way that it checks for the HTTP REMOTE_USER >> variable and uses that for active user. That restriction is only relaxed >> for users >> that are in the "admin" file mentioned. Every one else can't switch. >> > >> > We could relax that for other users but then we would need to have >> another source where we need to look for which other user one can switch. >> Something like this: >> > userA (can switch to): userB,userC,userD >> > >> > I could add something like that but I see it already. I see already 1 >> million users then going to ask that we add group functionality into >> that. >> Aka: >> > groupA (can manage): userA,userB,userC >> > >> > And then I see others asking for: >> > groupA (can manage): userA,userB,userC >> > groupB (can manage): userX,userY,userZ >> > groupC (can manage): groupA,groupB >> > userA (is member of): groupA >> > userB (is member of): groupB >> > userPaul (is member of): groupC >> > admin (is member of): ALL GROUPS >> > >> > And then I see others asking for: >> > groupA (can manage): userA,userB,userC >> > groupB (can manage): userX,userY,userZ >> > groupC (can manage): groupA,groupB >> > groupD (can manage): groupA,groupB,groupC >> > groupE (can manage): groupC but not members of groupB >> > >> > >> > And so on and so on.... you can imagine: It would be a never ending >> story since every one would at the beginning say that they could live >> with a >> flat file and then they start to fill in bug reports asking for feature >> A, >> then feature B and then for featureC and at the end the flat file >> solution is >> ultra terrible to maintain and very limited to work with and it would >> have >> been better to implement everything with a proper directory (aka LDAP or >> other solution) then going the simple road. >> > >> > But off course. At the beginning everyone and his dog will tell you >> > that >> a flat file is absolutely okay and that in NO WAY they would ever want >> more then that. In German we have an expression "Mit dem Essen kommt der >> Appetit".. That means: With eating comes the appetite. >> > >> > As soon as you give the small finger they (the users out there) are >> going to take/request the whole hand. And I don't know if doing now again >> a >> hack on top of another hack (the hack on top of the hack is the WebUI) is >> the >> right solution? >> > >> > >> > >> >> Pc >> >> >> >> >> > Steve >> > >> > >> ------------------------------------------------------------------------------ Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev _______________________________________________ Dspam-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspam-devel
