On Fri, 11 Dec 2009 16:14:57 +0100, "Steve" <[email protected]> wrote: > -------- Original-Nachricht -------- >> Datum: Fri, 11 Dec 2009 11:49:27 -0300 >> Von: "Edgar Díaz Orellana" <[email protected]> >> An: [email protected] >> Betreff: Re: [Dspam-devel] Control multiple users from one login on >> web-ui > >> Steve. >> > Hallo Edgar, Hi Steve. > > >> You'll absolutly own that pizza. >> > :) > > >> impressive work arround about create managers in a record time. !!!!! >> > Once you sit down and start coding things just flow. I had the advantage to > know Dojo so the whole thing was pretty easy for me. The Perl stuff was > more nasty. Not because of the language but because I have done everything > remote on a SSH terminal and coding in a nano editor is not the best > development environment and the dspam.cgi/admin.cgi are not the smallest > one. One looses quickly the overview. But it was okay. Could have been > worse. > That's true, currently i'm creating some stuff in xml for cisco telephones SCCP protocol and SIP protocol. it's nasty but it's really cool develop some features, i'm use vim, for color schema, better than nano. And it's true, the cgi in perl it's easy to miss the path, the code isn't to much clear to read at simple view.
> >> congratulations!!!!.. >> > Thanks. > > >> where i could find that hack to dspam cgi's?. >> > LOL. You really want it? I have unbugged the history in DSPAM but have NOT > jet had the time to look at the quarantine. I guess I need to invest a > bunch of minutes to verify that it works without issues when called from > within a layout. I can send you the new Web UI but you need to promise me > to send back some feedback. At least I need to know things that DON'T work > with the new Web UI. Would that be okay for you? You can install the new > Web UI in another directory on your web server and look how well it works. > You don't need to replace the current Web UI. > Don't worry, if i had some time, i could put an extra effort to try build the quarantine, but isn't sure i could bring time as soon i want it. And for sure, i bring all feedback for this hack. >> i really want to test that feature. >> > :) And I really NEED feedback. Not just for the Web UI. I need feedback > from you guys using already 3.9.0 in production. I want to hear your > opinions about 3.9.0. Is it useful? What is good? What is bad? What is a > show stopper for you? What would you like to have in DSPAM that could be > made later (aka 4.0.0 or 3.9.1)? etc... the more feedback, the better. > Currently for must at all "time" issues, i'm not upgrade the currently 3.8.6 stage on my email server, that's tricky too because i have arround 2000 email boxes on this server, and i don't have enough time to compile and publish an .deb for the debian server on the production environment. i'm start to think about create a virtual server for my currently domain, then strart try the 3.9 stage for my own server, for testing and feedback. >> thanks for your work my friend. >> > It's just a quick hack. I mean: It's quickly done. The code it self is > clean. Much cleaner then the current Web UI code. > i know about it's just a quick hack, but thanks at all. every effort to bring better tools, even the smallest always be appreciated. > >> Edgar >> > Steve > Edgar PS: hope my english is clear to read and not be too messy for understand. hope too it's not an "me tarzan you jane" type of english. apologies to everyone if my english isn't too clear. > >> >> 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 ------------------------------------------------------------------------------ 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
