> Hi Steve. > > Halo Edgar,
> > > 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. > Yeah. That's what I meant. > 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. > No, no, no. The quarantine works. It is just that every link inside of those generated pages (history, quarantine, user listing, etc) have links to http://server/dspamui/dspam.cgi?user=blahblahblah&template=quarantine&action=whatever And to avoid the reloading of the tabbed layout I modified the links inside history to work differently. BUT I have not done that for the quarantine. And since quarantine is build the same way as the history I am guessing that I need to do some minor changes to polish up the quarantine to not make an extra round-trip to the server. That's all. Do you understand what I mean? > And for sure, i bring all feedback for this hack. > THANKS! Okay. Should I send it to the above address or do you have another address you would like me to use? > Currently for must at all "time" issues, i'm not upgrade the currently > 3.8.6 > 3.8.6? You probably mean 3.6.8. Or? > 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. > Julian has build .deb files for anything since we started with pushing out betas. > 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. > Do that. You will be surprised how easy the upgrade from 3.6.8 -> 3.8.0 -> 3.9.0 is or from 3.6.8 -> 3.9.0 If I would be in your shoes then I would COPY production on the VM (just the DSPAM part) and then do a migration in the VM and look what issues you have and then fix them and document them. When done with everything and when having a working 3.9.0 I would again DELETE everything in the VM and redo the job again but this time following the documented steps and see if you still get a working 3.9.0. I would measure the time and then I would plan the migration from 3.6.8 to 3.9.0. > 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. > I really hope others will come finally out of their snail shell and commit some time for the project. I feel often alone :( > Edgar > Steve > 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. > > Your English is good. Someone writing about "me Tarzan, you Jane" definitely understands English. > >> > >> 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 -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser ------------------------------------------------------------------------------ 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
