Reply-To: Okay I don't know how I've gone and done such a stupid thing....(working with zope while I was too tired) but I've locked myself out of a folder that has a GUF under it. Do I have any recourse (other than delete the folder which hasa few dtml methods I would rather not recreate) and start over? I've tried undo but I had already packed my database. The __no_before_traverse__ doesn't work with this unfortunatly. Any tips? Or places to look for said tips? Thakns in advance, -- John E. Vincent http://www.lusis.org - opensource(libre) webhosting http://www.jyradelix.com - Jyradelix Designs http://www.lusis-integrations.com - Lusis Network Integration Consultants --------------- "Some people call me crazy but I prefer to think of myself as a freelance lunatic" - me
John E . Vincent writes:
Reply-To: Okay I don't know how I've gone and done such a stupid thing....(working with zope while I was too tired) but I've locked myself out of a folder that has a GUF under it. Do I have any recourse (other than delete the folder which hasa few dtml methods I would rather not recreate) and start over? I've tried undo but I had already packed my database. The __no_before_traverse__ doesn't work with this unfortunatly. Any tips? Or places to look for said tips?
I managed to do this twice recently (doh!) under a couple of different circumstances. In the first case I had just one GUF as the base acl_users folder which wasn't finished. I managed to get superuser access again by: - Shutting down zope, - backing up the var/ directory with Data.fs under it and creating a fresh one, - starting up zope and logging into the management section. - shut down zope (but keep the browser session running) - swap back your old var directory and start up zope - move the offending acl_users folder to some subfolder. It seems that your already established authorization for that domain is enough to fool Zope into thinking that you are authorized to work with the different copy of the database. The second problem I had was that I couldn't access the folder that I'd put the GUF under - this was because I hadn't recreated a new standard acl_user folder under the root folder. Hope this helps. John.
On Wed, Feb 23, 2000 at 10:06:57AM +1300, John Morton spake unto the masses:
John E . Vincent writes:
Reply-To: Okay I don't know how I've gone and done such a stupid thing....(working with zope while I was too tired) but I've locked myself out of a folder that has a GUF under it. Do I have any recourse (other than delete the folder which hasa few dtml methods I would rather not recreate) and start over? I've tried undo but I had already packed my database. The __no_before_traverse__ doesn't work with this unfortunatly. Any tips? Or places to look for said tips?
I managed to do this twice recently (doh!) under a couple of different circumstances. In the first case I had just one GUF as the base acl_users folder which wasn't finished. I managed to get superuser access again by:
- Shutting down zope, - backing up the var/ directory with Data.fs under it and creating a fresh one, - starting up zope and logging into the management section. - shut down zope (but keep the browser session running) - swap back your old var directory and start up zope - move the offending acl_users folder to some subfolder. I'm glad only root has access to do this quite honestly but couldn't someone figure out a way to take advantage of this? Of course if they have access to root on your box you have bigger problems. I'm just wondering if some sort of previously established trust could be used in the same way. I think that was the issue that was fixed in 2.1.4, no?
Needless to say this worked just fine. I actually tried one of the other suggestions about exporting as xml but the only way I could see around that is to change all the id's that are assigned in the xml to not skip any id numbers. I gave up on that straight away. Thanks for the help! Now I'm going to try and do this on a test folder and NOT mess something up ;)
It seems that your already established authorization for that domain is enough to fool Zope into thinking that you are authorized to work with the different copy of the database.
The second problem I had was that I couldn't access the folder that I'd put the GUF under - this was because I hadn't recreated a new standard acl_user folder under the root folder.
Hope this helps.
John.
-- John E. Vincent http://www.lusis.org - opensource(libre) webhosting http://www.jyradelix.com - Jyradelix Designs http://www.lusis-integrations.com - Lusis Network Integration Consultants --------------- "Some people call me crazy but I prefer to think of myself as a freelance lunatic" - me
"John E . Vincent" wrote:
Reply-To: Okay I don't know how I've gone and done such a stupid thing....(working with zope while I was too tired) but I've locked myself out of a folder that has a GUF under it. Do I have any recourse (other than delete the folder which hasa few dtml methods I would rather not recreate) and start over? I've tried undo but I had already packed my database. The __no_before_traverse__ doesn't work with this unfortunatly. Any tips? Or places to look for said tips?
You _could_ try to export the folder to xml and then poke around in the export file with an editor (maybe even with some structured XML editor ;) and try to at least salvage your methods. Maybe You can even descipher the format enough to put back the inherited roles and/or remove GUF. I've had similar (but lighter) annoyances when I have added a user with the same name as the zope superuser (but without Manage role) in GUF/UserDB Just removing/renaming said user fixed the problem then. -------------- Hannu
participants (3)
-
Hannu Krosing -
John E . Vincent -
John Morton