RE: [Zope] Major security flaw in Zope 2.3.2
That's all well and good, but users should be able to reasonably expect that their passwords be secure from prying administrators. Sure, an admin could brute force or guess a *nix password, but they aren't cleartext. The only easy way for an admin to get a user's passwd is to chage it (nevermind the 'su username' act). Zope stores it's data in a database, with a seperate security system from the filesystem. These passwords should not be cleartext anymore than you would select the cleartext option for your inituser or access file. Troy -----Original Message----- From: Frank Tegtmeyer [mailto:fte@lightwerk.com] Sent: Wednesday, June 06, 2001 8:26 AM To: zope@zope.org Subject: Re: [Zope] Major security flaw in Zope 2.3.2 On Wed, Jun 06, 2001 at 02:43:48PM +0200, Jerome Alet wrote:
* make Data.fs and Data.fs.old only readable by a user every other user on the system can't run commands as.
Anyone out there who does *not* do that? Regards, Frank _______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
On Wed, Jun 06, 2001 at 08:40:44AM -0500, Farrell, Troy wrote:
That's all well and good, but users should be able to reasonably expect that their passwords be secure from prying administrators.
Of course that's a valid point and I was not arguing against it. I only picked the most problematic part of the scenario. In fact one way encryption is cheap and available everywhere, so it should be no problem to integrate it. Of course it would not help against a prying administrator. It's plain simple to sniff the passwords from HTTP traffic. Regards, Frank
snip
Of course it would not help against a prying administrator. It's plain simple to sniff the passwords from HTTP traffic.
Regards, Frank
And that's why you shouldn't allow access to the management interface via HTTP. (I just wonder why there is a *separate* ZServer with SSL capabilities and why SSL isn't simply integrated into the standard ZServer. Does anybody know?) I simple 'Deny from all' all accesses to any url containing 'manage' on port 80 so that noone accidentally sends a password in cleartext. Ragnar
On Wed, 6 Jun 2001 16:02:11 +0200, Ragnar Beer <rbeer@uni-goettingen.de> wrote:
(I just wonder why there is a *separate* ZServer with SSL capabilities and why SSL isn't simply integrated into the standard ZServer. Does anybody know?)
For the security concious, ZServer is not quite tough enough to be exposed to the raw internet. If you have to use something like Apache as a front-end proxy anyway, then it might as well handle SSL too. Toby Dickenson tdickenson@geminidataloggers.com
Do many installs use this approach? Any issues with using Apache SSL as a passthru ?? I'm hoping performance impacts using this approach will be minimal. rich
For the security concious, ZServer is not quite tough enough to be exposed to the raw internet. If you have to use something like Apache as a front-end proxy anyway, then it might as well handle SSL too.
Toby Dickenson tdickenson@geminidataloggers.com
Do many installs use this approach? Any issues with using Apache SSL as a passthru ?? I'm hoping performance impacts using this approach will be minimal.
I use.... Apache -> Squid -> Zope ...with negligible additional latency at moderate loads. Toby Dickenson tdickenson@geminidataloggers.com
I never thought of having Squid between Apache and Zope but it sounds very interesting. What's the advantage over mod_proxy? Ragnar
I use....
Apache -> Squid -> Zope
...with negligible additional latency at moderate loads.
Toby Dickenson
On Wed, 6 Jun 2001 22:03:57 +0200, Ragnar Beer <rbeer@uni-goettingen.de> wrote:
Apache -> Squid -> Zope
I never thought of having Squid between Apache and Zope but it sounds very interesting. What's the advantage over mod_proxy?
Squid's caching implementation seems to be more sophisticated; both in terms of its handling of the HTTP caching headers, and the number of things to tweak in squid.conf. If caching is crucial to your site then I think Squid has a higher hit-rate ceiling, if you are willing to invest some time in handling HTTP caching headers in your Zope application. However, I never really because proficient with mod_proxy's caching. It was difficult to understand why certain requests were cached, and others not, and difficult to obtain performance measures direct from the cache. In contrast Squid can write detailed logs, and provides alot of detailed information through a web-based management interface. Squid makes the whole system more debuggable. Another reasonable question is why I use both Squid and Apache, rather than just Squid...... I find Apache good for virtual hosting, and using mod_rewrite to glue various back-end resources into a single URL namespace. Toby Dickenson tdickenson@geminidataloggers.com
Ragnar Beer wrote:
snip
Of course it would not help against a prying administrator. It's plain simple to sniff the passwords from HTTP traffic.
Regards, Frank
And that's why you shouldn't allow access to the management interface via HTTP. (I just wonder why there is a *separate* ZServer with SSL capabilities and why SSL isn't simply integrated into the standard ZServer. Does anybody know?) I simple 'Deny from all' all accesses to any url containing 'manage' on port 80 so that noone accidentally sends a password in cleartext.
perhaps a more user friendly solution would be to redirect/rewrite/... :80/manage to :443/manage I don't know by heart how to do this in apache, but if I find it I'll post it to the list.
Ragnar
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
On Wed, 6 Jun 2001, Ragnar Beer wrote:
Of course it would not help against a prying administrator. It's plain simple to sniff the passwords from HTTP traffic.
Regards, Frank
And that's why you shouldn't allow access to the management interface via HTTP. (I just wonder why there is a *separate* ZServer with SSL
This is of not much help. Prying admin who already has access to filesystem will just hack Zope and get passwords mailed to him, SSL or no SSL - right from Zope. Oleg. ---- Oleg Broytmann http://www.zope.org/Members/phd/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN.
Of course it would not help against a prying administrator. It's plain simple to sniff the passwords from HTTP traffic.
And that's why you shouldn't allow access to the management interface via HTTP. (I just wonder why there is a *separate* ZServer with SSL
This is of not much help. Prying admin who already has access to filesystem will just hack Zope and get passwords mailed to him, SSL or no SSL - right from Zope.
If you can't trust your admin. Get another admin.
On Wed, 6 Jun 2001, Steve Drees wrote:
Of course it would not help against a prying administrator. It's plain simple to sniff the passwords from HTTP traffic.
And that's why you shouldn't allow access to the management interface via HTTP. (I just wonder why there is a *separate* ZServer with SSL
This is of not much help. Prying admin who already has access to filesystem will just hack Zope and get passwords mailed to him, SSL or no SSL - right from Zope.
If you can't trust your admin. Get another admin.
If you trust your admin - why do you need to encrypt Zope passwords? Oleg. ---- Oleg Broytmann http://www.zope.org/Members/phd/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN.
On Wed, 6 Jun 2001, Ragnar Beer wrote:
Of course it would not help against a prying administrator. It's plain simple to sniff the passwords from HTTP traffic.
Regards, Frank
And that's why you shouldn't allow access to the management interface via HTTP. (I just wonder why there is a *separate* ZServer with SSL
This is of not much help. Prying admin who already has access to filesystem will just hack Zope and get passwords mailed to him, SSL or no SSL - right from Zope.
Oleg.
Absolutely right. I wasn't referring to sniffing admins here but to sending plaintext passwords over HTTP in general. Ragnar
And dont forget you can tie all passwords to an IP as well. So they have to spoof their IP too. Cheers. -- Andy McKay.
On Wed, 6 Jun 2001, Ragnar Beer wrote:
And that's why you shouldn't allow access to the management interface via HTTP. (I just wonder why there is a *separate* ZServer with SSL
This is of not much help. Prying admin who already has access to filesystem will just hack Zope and get passwords mailed to him, SSL or no SSL - right from Zope.
Oleg.
Absolutely right. I wasn't referring to sniffing admins here but to sending plaintext passwords over HTTP in general.
This has nothing with encryprint passwords in ZODB. You want - and I completeley agree - that we need encrypted browser<=>server sessions... well there is Apache+SSL. Oleg. ---- Oleg Broytmann http://www.zope.org/Members/phd/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN.
On Wed, 6 Jun 2001 15:42:15 +0200, Frank Tegtmeyer <fte@lightwerk.com> wrote:
In fact one way encryption is cheap and available everywhere, so it should be no problem to integrate it.
... but makes it harder to integrate other mechanisms for *checking* the password, such as digest authentication. Toby Dickenson tdickenson@geminidataloggers.com
On Wed, Jun 06, 2001 at 08:41:06AM -0500, Farrell, Troy wrote:
security system from the filesystem. These passwords should not be cleartext anymore than you would select the cleartext option for your inituser or access file.
That's exactly what surprised me the most: you can select an encryption method for the initial user's password, but all other passwords are stored unencrypted. IMHO this is a trivial patch: We agree that passwords travel basically unencrypted over the wires, so we can't do anything there. However everytime we receive a password from the network, just encrypt it and compare it against the encrypted password which is stored in the ZODB. Of course for every new user of every password change, store the password in an encrypted form (MD5 will do). The patch should be an one (or two) liner (although I've not verified) and should be transparent for everyone. bye, Jerome Alet
On Wed, Jun 06, 2001 at 08:41:06AM -0500, Farrell, Troy wrote:
security system from the filesystem. These passwords should not be cleartext anymore than you would select the cleartext option for your inituser or access file.
The patch should be an one (or two) liner (although I've not verified) and should be transparent for everyone.
Hi folks - There has been a proposal by Ross Lazarus about this since Jan. 28, 2001: http://dev.zope.org/Wikis/DevSite/Proposals/EncryptedUserfolderPasswords It is a little more than a 2 or 3 line patch; please read what's already there, add your comments, help us to work out the conversion issues, and help us get a sense of priority for this. It is rather dispiriting to see a "shocking major security flaw!" thread about something that has been quite visible in the proposals area for nearly 6 months. :( Please let me know if you have ideas for improvements we can make to the fishbowl to encourage more people to use it. Brian Lloyd brian@digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com
On Wed, Jun 06, 2001 at 02:22:28PM -0400, Brian Lloyd wrote:
http://dev.zope.org/Wikis/DevSite/Proposals/EncryptedUserfolderPasswords
I didn't know that.
It is a little more than a 2 or 3 line patch; please read what's already there, add your comments, help us to work out the conversion issues, and help us get a sense of priority for this.
I'll try to give it a look.
It is rather dispiriting to see a "shocking major security flaw!" thread about something that has been quite visible in the proposals area for nearly 6 months. :(
Sorry, I understand your feelings. I was so shocked to discover this that I've posted in a too emotional spirit I suppose. The very disturbing thing is the fact that the inituser file is encrypted, so I was confident that all other passwords were encrypted. However this problem doesn't need another 6 months or so for a solution.
Please let me know if you have ideas for improvements we can make to the fishbowl to encourage more people to use it.
Yes, as Oleg would probably say: put all this in a mailing list ! bye, Jerome Alet
On Wed, Jun 06, 2001 at 02:22:28PM -0400, Brian Lloyd wrote:
There has been a proposal by Ross Lazarus about this since Jan. 28, 2001:
http://dev.zope.org/Wikis/DevSite/Proposals/EncryptedUserfolderPasswords
I've read it. So just a question: What are you waiting for before implementing it ? The proposed patch complete with method definition and docstring, taking care of two different encryption methods is 13 lines long ! Just what I called a one liner. The original author didn't submit a patch to encrypt all unencrypted user passwords to take care of existing Data.fs files, so what ? Do you want me to write it ? Every time Zope is launched and recreate its index, just take care of it, encrypt unencrypted passwords and update the ZODB automatically. This wouldn't slow down Zope when running, only when it's restarted. I understand that there's the problem of existing third party products which may expect unencrypted passwords: just do it anyway and inform people. I suppose there won't be hundreds of such third party products. Just do a poll: does any reader of this list expects such a bad behavior in his own Zope products ? bye, Jerome Alet
Jerome Alet wrote:
I understand that there's the problem of existing third party products which may expect unencrypted passwords: just do it anyway and inform people. I suppose there won't be hundreds of such third party products.
Just do a poll: does any reader of this list expects such a bad behavior in his own Zope products ?
Afaik, the only bad behaviour from hashing (_not_ encrypting) the passwords would be the impossibility to use password verification methods that don't send cleartext passwords over the wire (challenge-response password exchange). But as the preferred method for avoid password sniffing is using ssl anyway I don't think it is too much of a problem. ----------------- Hannu
On Thu, Jun 07, 2001 at 12:00:44AM +0500, Hannu Krosing wrote:
Afaik, the only bad behaviour from hashing (_not_ encrypting) the passwords would be the impossibility to use password verification methods that don't send cleartext passwords over the wire (challenge-response password exchange).
The "PHPlib" package for PHP provides a challenge-response authentication scheme where the browser runs a javascript function to hash the user-supplied password value before sending it as form data. If javascript is disabled or not available, the clear-text password is sent instead and the value hashed at the server to match against the stored value. -- Fred Yankowski fred@OntoSys.com tel: +1.630.879.1312 Principal Consultant www.OntoSys.com fax: +1.630.879.1370 OntoSys, Inc 38W242 Deerpath Rd, Batavia, IL 60510, USA
Fred Yankowski wrote:
On Thu, Jun 07, 2001 at 12:00:44AM +0500, Hannu Krosing wrote:
Afaik, the only bad behaviour from hashing (_not_ encrypting) the passwords would be the impossibility to use password verification methods that don't send cleartext passwords over the wire (challenge-response password exchange).
The "PHPlib" package for PHP provides a challenge-response authentication scheme where the browser runs a javascript function to hash the user-supplied password value before sending it as form data. If javascript is disabled or not available, the clear-text password is sent instead and the value hashed at the server to match against the stored value.
Just sending a hashed value does not make it any more secure, as said hashed value is as easy to sniff as plaintext. to have a real challenge response, something like the following must be done: SERVER: generates a random string RS and sends RS to client CLIENT: MD5(password+RS) and sends this back to server SERVER: compares hash sent by client to locally computed MD5(password+RS) for this to work the server needs to know the plaintext password -------------- Hannu
On Thu, Jun 07, 2001 at 05:06:55PM +0200, Hannu Krosing wrote:
Just sending a hashed value does not make it any more secure, as said hashed value is as easy to sniff as plaintext.
Sorry, I over-simplified my description of the PHPlib scheme. Server: Generate new challenge value. Send login form with challenge value as value of hidden form field. Client: Collect username and password on form. If Javascript enabled, create MD5 hash of password value, create MD5 hash from concatenation of username, MD5-hashed password, and challenge. Save latter hash value in hidden form field. Server: If hidden form field has a value, create MD5 hash from username, password (from database, stored already MD5-hashed), and challenge; compare that value against the one sent by the client to authenticate. If hidden form field has no hash value (client didn't run javascript code), do MD5 hash on clear-text password sent by client and compare against database value for given username to authenticate. -- Fred Yankowski fred@OntoSys.com tel: +1.630.879.1312 Principal Consultant www.OntoSys.com fax: +1.630.879.1370 OntoSys, Inc 38W242 Deerpath Rd, Batavia, IL 60510, USA
Brian Lloyd wrote:
It is rather dispiriting to see a "shocking major security flaw!" thread about something that has been quite visible in the proposals area for nearly 6 months. :(
Please let me know if you have ideas for improvements we can make to the fishbowl to encourage more people to use it.
Well, there's no notification which is the main thing that stops it being useful for me. I stick in comments and proposals when I remember but I don't have time to check the _whole_ of the Fishbowl every day, and I'm too stupid for the RecentChanges page to spark off the right neurons when something I'm interested in changes (it also becomes much less useful when _lots_ of things are changing of which you're only interested in a few, as in a busy Wiki like the fishbowl) Maybe if it was a CMF site with subscriber lists for each proposal (which would be a content object, not just a bit of a Wiki)? I'm now working on Swishdot which aims to have subscriber lists, but I'm a long way off right now... My £0.02, Chris :-)
On Thu, 7 Jun 2001, Chris Withers wrote:
Brian Lloyd wrote:
Please let me know if you have ideas for improvements we can make to the fishbowl to encourage more people to use it.
I'm now working on Swishdot which aims to have subscriber lists, but I'm a long way off right now...
and an automatic announce in zope@zope.org about new topics to which we can subscribe. I personnally regret that my days aren't 28 hours long, but them being only 24 hours I can't spend a lot of time surfing the web in wikis while a mailing list would be an enormous time saver instead: Wikis are maybe great to organise, archive, and keep track of small modifications, for proposals AFTER they have been discussed on a mailing list, but IMHO they can't replace a mailing list to discuss about the evolution of free softwares because they are just too slow. bye, Jerome Alet
I posted a comment on a "dogfishbowl" last week on zope-dev. Im not sure how much I can do from outside Zope.org though... maybe put it on ZopeZen ;) http://aspn.activestate.com/ASPN/Mail/msg/zope-Dev:550249 Cheers. -- Andy McKay. ----- Original Message ----- From: "Chris Withers" <chrisw@nipltd.com> To: "Brian Lloyd" <brian@digicool.com> Cc: "Jerome Alet" <alet@unice.fr>; "Farrell, Troy" <troy.farrell@wcg.com>; <zope@zope.org> Sent: Thursday, June 07, 2001 5:54 AM Subject: [Zope] Making the Fishbowl Better :-)
Brian Lloyd wrote:
It is rather dispiriting to see a "shocking major security flaw!" thread about something that has been quite visible in the proposals area for nearly 6 months. :(
Please let me know if you have ideas for improvements we can make to the fishbowl to encourage more people to use it.
Well, there's no notification which is the main thing that stops it being useful for me.
I stick in comments and proposals when I remember but I don't have time to check the _whole_ of the Fishbowl every day, and I'm too stupid for the RecentChanges page to spark off the right neurons when something I'm interested in changes (it also becomes much less useful when _lots_ of things are changing of which you're only interested in a few, as in a busy Wiki like the fishbowl)
Maybe if it was a CMF site with subscriber lists for each proposal (which would be a content object, not just a bit of a Wiki)?
I'm now working on Swishdot which aims to have subscriber lists, but I'm a long way off right now...
My £0.02,
Chris :-)
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Hi Andy, I hope you dont mind the emails.. I'm basically sending you my brainstream about your timesaving product Two suggestions: 1) Have a 'ignore' status for each item, with a grey box. That way certain items will never be compared in the XMLRPC stream and are safe. 2) Is it possible to check that an object is a product and a product that would not allow transfer, such as SQLSession object. Things I've noticed: 3) An Authorization request is thrown when trying sync apparently non-syncable objects (my SQLSession objects). I tried using a manageinterface added user and it had no difference than superuser in inituser. The Authentication is an impossible one because it doesnt accept the correct password and then after 3 tries you get the gratuitous page 4) Sometimes in root, a folder will be green, but you know there are contents that are not. Go into that folder and you have some items that are yellow. 5) Sometimes in a folder, EVERYTHING is yellow (out of date) when you know only one is. This is SCARING the shit out of me because i work on a site that has a folder which does credit transactions... Not knowing what is going on there is dangerous. If you update the object anyways, what happens I wonder? Hope this helps you, I'll continue to send my notes if you want them... Paz
Hi Andy,
I hope you dont mind the emails.. I'm basically sending you my brainstream about your timesaving product
No thats fine, glad its being used.
Two suggestions: 1) Have a 'ignore' status for each item, with a grey box. That way certain items will never be compared in the XMLRPC stream and are safe.
Yeah, I was thinking of hardcoding in some ignore values, but also allowing arbitrary objects to be ignored. The big problem here is *folders*. If you sync the containing folder, it will happily sync all the subobjects, ignoring these objects you told it to ignore. What we need to be able to do is separate and somehow sync each object individually, thats really tricky to do, folders are a problem.
2) Is it possible to check that an object is a product and a product that would not allow transfer, such as SQLSession object.
I dont know how I could check that... if make the ignore list an option for the user, once they find and object that cant be synced, they can add it to the list for their ZSyncer.
3) An Authorization request is thrown when trying sync apparently non-syncable objects (my SQLSession objects). I tried using a manageinterface added user and it had no difference than superuser in inituser. The Authentication is an impossible one because it doesnt accept the correct password and then after 3 tries you get the gratuitous page
If a product behaves funnily theres not a lot I can do. Error could be nice though. See point 2.
4) Sometimes in root, a folder will be green, but you know there are contents that are not. Go into that folder and you have some items that are yellow.
Yes folders again. If you change an object in folder, the object becomes out of date. However since you have not changed the folder, it is still green. Now if you rename, add, delete, copy, cut into / out of that folder (ie change the number of objects) the folder has changed. Hence the folder is now out of date. Folders are a problem.
5) Sometimes in a folder, EVERYTHING is yellow (out of date) when you know only one is. This is SCARING the shit out of me because i work on a site that has a folder which does credit transactions... Not knowing what is going on there is dangerous. If you update the object anyways, what happens I wonder?
Well dont use it then, please dont screw up your site with it. We sync what we know to need changing, figuring what has changed is still fraught with problems. The problem is we are comparing date / times on objects and sometimes they just appear to be plain wrong. Especially if you are syncing to a box in a different time zone! What is needed is something me and Gregor are talking about, a version number on each object, similar to CVS. By comparing the number of a version, we eliminate this problem. -- Andy McKay
The problem is we are comparing date / times on objects and sometimes they just appear to be plain wrong. Especially if you are syncing to a box in a different time zone! What is needed is something me and Gregor are talking about, a version number on each object, similar to CVS. By comparing the number of a version, we eliminate this problem.
Is this somehow related to the mxDateTime thread and something about Zope returning DateTime objects as strings? Perhaps using mxDateTime is a good idea then? Personally, I've lost alot of time wrestling with DateTimes that sometimes go into a sql table and sometimes not. I had assumed it was just my newbieness (and still do) but something tells me I'm not as stupid as I think I am :-) Cheers Andy, Paz
Is this somehow related to the mxDateTime thread and something about Zope returning DateTime objects as strings? Perhaps using mxDateTime is a good idea then? Personally, I've lost alot of time wrestling with DateTimes that sometimes go into a sql table and sometimes not. I had assumed it was just my newbieness (and still do) but something tells me I'm not as stupid as I think I am :-)
I think just comparing date times is just inherently problematic, there has to be a better way for this particular application. The ZSyncer aint CVS, yet :) Cheers. -- Andy McKay.
Agreable, but regarding one point that if things are a bit funny, dont use it. It's either useable or not in this context, so is there anything you can add as far as the risks involved? Let me state a scenario: A subfolder you have entered in ZSync has almost ALL items as out of date but you know only one or two are ACTUALLY out of date. What could happen if you sync the in-date, out of date items? From the way I see it, it only refreshes the copy of the object to be (theoretically) the same as it was before the update... (follow me?) Is it possible that this misnomered sync could cause garbage to go in, or clear the contents of the object or....
From what you say that only the datetime is compared, than if the site you are working on is fully functional, then a misnomered sync in fact doesnt do anything, except for update the datetime to what it understands as 'proper'
Have I confused you sufficiently? ; ) Paz -----Original Message----- From: Andy McKay [mailto:andym@ActiveState.com] Sent: 08 June 2001 17:47 To: Paul Zwarts Cc: Zope Subject: Re: [Zope] More ZSyncer stuff
Is this somehow related to the mxDateTime thread and something about Zope returning DateTime objects as strings? Perhaps using mxDateTime is a good idea then? Personally, I've lost alot of time wrestling with DateTimes that sometimes go into a sql table and sometimes not. I had assumed it was just my newbieness (and still do) but something tells me I'm not as stupid as I think I am :-)
I think just comparing date times is just inherently problematic, there has to be a better way for this particular application. The ZSyncer aint CVS, yet :) Cheers. -- Andy McKay.
Agreable, but regarding one point that if things are a bit funny, dont use it. It's either useable or not in this context, so is there anything you can add as far as the risks involved?
Thats open source for ya. Remember I just released ZSyncer for the heck of it from an internal project where it works just fine...
Let me state a scenario:
A subfolder you have entered in ZSync has almost ALL items as out of date but you know only one or two are ACTUALLY out of date. What could happen if you sync the in-date, out of date items? From the way I see it, it only refreshes the copy of the object to be (theoretically) the same as it was before the update... (follow me?)
The same as it always does. It will replace the copy on the destination server with the one on your source server.
Is it possible that this misnomered sync could cause garbage to go in, or clear the contents of the object or....
Nope, it will replace the copy on the destination server with the one on your source server.
From what you say that only the datetime is compared, than if the site you are working on is fully functional, then a misnomered sync in fact doesnt do anything, except for update the datetime to what it understands as 'proper'
It will replace the copy on the destination... etc. A by product of this sync is to reset the date.
Have I confused you sufficiently? ; )
Im sufficiently confused everyday anyway... -- Andy McKay.
----- Original Message ----- From: "Paul Zwarts" <paz@oratrix.com> To: "Andy" <andy@agmweb.ca> Cc: "Zope" <zope@zope.org> Sent: Friday, June 08, 2001 11:38 AM Subject: RE: [Zope] More ZSyncer stuff
Is this somehow related to the mxDateTime thread and something about Zope returning DateTime objects as strings? Perhaps using mxDateTime is a good idea then? Personally, I've lost alot of time wrestling with DateTimes
that
sometimes go into a sql table and sometimes not. I had assumed it was just my newbieness (and still do) but something tells me I'm not as stupid as I think I am :-)
There is currently a proposal to replace DateTime by mxDateTime: http://dev.zope.org/Wikis/DevSite/Proposals/ReplacingDateTime Feel free to comment. Andreas
Andy wrote:
No thats fine, glad its being used.
I have 'big' plans for it also. <s> The problem right now is time of course. Thankfully Paul is helping get the kinks out. :-)
4) Sometimes in root, a folder will be green, but you know there are contents that are not. Go into that folder and you have some items that are yellow.
Yes folders again. If you change an object in folder, the object becomes out of date. However since you have not changed the folder, it is still green. Now if you rename, add, delete, copy, cut into / out of that folder (ie change the number of objects) the folder has changed. Hence the folder is now out of date.
Could you not mark an objects container out of date when the object is out of date? Thousands of object would probably create a lot of wasted overhead so you could set a falg if the container was already marked?
The problem is we are comparing date / times on objects and sometimes they just appear to be plain wrong. Especially if you are syncing to a box in a different time zone! What is needed is something me and Gregor are talking about, a version number on each object, similar to CVS. By comparing the number of a version, we eliminate this problem.
This sounds like a much better solution. Can you do this with DTML Methods, Python Scripts ...? -- Tim Cook, President - FreePM,Inc. http://www.FreePM.com Office: (731) 884-4126 ONLINE DEMO: http://www.freepm.org:8080/FreePM
I have 'big' plans for it also. <s> The problem right now is time of course. Thankfully Paul is helping get the kinks out. :-)
Great, me and Gregor Heine are slowly getting around to getting a Sourceforge project up and running for this... http://sourceforge.net/projects/zsyncer not much there yet.
Could you not mark an objects container out of date when the object is out of date? Thousands of object would probably create a lot of wasted overhead so you could set a falg if the container was already marked?
Hmm... you couldnt really set a flag since that means changing the containers behavour. But the you could figure it out programmatically from looking at the containing objects. But the destination server would have to report more information back to the source to calculate this (since my destination servers are production servers I like to keep this to a minimum) and secondly how about sub-sub-folders, if there is something 5 levels down that has changed, how many containerish objects up should it go saying its changed. If im not careful I will be doing a very expensive comparison of the whole ZODB.... hmmmm.
This sounds like a much better solution. Can you do this with DTML Methods, Python Scripts ...?
It is, theres the thing... a patch to SimpleItem, ObjectManager and half of Zope and we are away. Cheers. -- Andy McKay.
On 06 Jun 2001 19:59:47 +0200, Jerome Alet wrote:
On Wed, Jun 06, 2001 at 08:41:06AM -0500, Farrell, Troy wrote:
security system from the filesystem. These passwords should not be cleartext anymore than you would select the cleartext option for your inituser or access file.
That's exactly what surprised me the most:
you can select an encryption method for the initial user's password, but all other passwords are stored unencrypted.
IMHO this is a trivial patch: We agree that passwords travel basically unencrypted over the wires, so we can't do anything there. However everytime we receive a password from the network, just encrypt it and compare it against the encrypted password which is stored in the ZODB.
Of course for every new user of every password change, store the password in an encrypted form (MD5 will do).
The patch should be an one (or two) liner (although I've not verified) and should be transparent for everyone.
You could probably pull the password encryption from ZMC. ZMC already defaults to encrpyted storage/comparing.
From: "Jerome Alet" <alet@unice.fr>
Of course for every new user of every password change, store the password in an encrypted form (MD5 will do).
The patch should be an one (or two) liner (although I've not verified) and should be transparent for everyone.
Keep in mind that there's a price to be paid, here. Since HTTP is connectionless, interacting with Zope requires re-authenticating on every request. If you're going to have a lot of requests that require authentication, you want it to be computationally inexpensive. On the other hand, if the only people logging in are a few developers, it's not a problem. Cheers, Evan @ digicool & 4-am
On Wed, 6 Jun 2001, Evan Simpson wrote:
From: "Jerome Alet" <alet@unice.fr>
Of course for every new user of every password change, store the password in an encrypted form (MD5 will do).
The patch should be an one (or two) liner (although I've not verified) and should be transparent for everyone.
Keep in mind that there's a price to be paid, here. Since HTTP is connectionless, interacting with Zope requires re-authenticating on every request. If you're going to have a lot of requests that require authentication, you want it to be computationally inexpensive. On the other hand, if the only people logging in are a few developers, it's not a problem.
You're right. so why not make it an option (not reversable) which would default to the safe "passwordhash=YES", and which would allow computational intensive sites (many authenticated requests a day) to disable it knowingly after having properly secured access to Data.fs AND Data.fs.old This would also prevent any problem with the hypotethical existing products which expect unencrypted passwords, until they are corrected. bye, Jerome Alet
From: "Jerome Alet" <alet@unice.fr>
so why not make it an option (not reversable) which would default to the safe "passwordhash=YES", and which would allow computational intensive sites (many authenticated requests a day) to disable it knowingly after having properly secured access to Data.fs AND Data.fs.old
Don't tell me, I'll just nod wisely and forget five seconds later ;-) Tell http://dev.zope.org/Wikis/DevSite/Proposals/EncryptedUserfolderPasswordsDisc ussion. Cheers, Evan @ digicool & 4-am
On Thu, 7 Jun 2001, Evan Simpson wrote:
Don't tell me, I'll just nod wisely and forget five seconds later ;-)
Tell http://dev.zope.org/Wikis/DevSite/Proposals/EncryptedUserfolderPasswordsDisc ussion.
done. bye, Jerome Alet
participants (20)
-
Andreas Jung -
Andy -
Andy McKay -
Bill Anderson -
Brian Lloyd -
Chris Withers -
Evan Simpson -
Farrell, Troy -
Frank Tegtmeyer -
Fred Yankowski -
Hannu Krosing -
Jerome Alet -
Maarten Slaets -
Oleg Broytmann -
Paul Zwarts -
Ragnar Beer -
Rich Pinder -
Steve Drees -
Tim Cook -
Toby Dickenson