Open frisco opened 12 years ago
opengeek submitted:
Are you using rewrite rules? Sounds like they are disrupting the requests.
kevin.marvin submitted:
Frisco:
I've had a similar problem with Lighttpd recently. I added the following lines to the vhost config area for the site and solved the issue...
url.redirect = (
"^/manager$" => "/manager/"
)
The issue is that the router for lighty gets a little confused when you are attempting to reach /managerindex.php?a=88 - forcing it to redirect requests from /manager (initially) to /manager/ should resolve the problem.
Thanks,
Frisco submitted:
Sorry for the delay, I was to christmas holidays.
@Kevin: Thanks for pointing me to url.redirect, that helped solving the issue of the manager jumping to the web context - but it's not connected to my problem with the user management, thus this problems remains.
@Jason: As the problem with the rewrite rules is solved (thanks to Kevin) and the problem with the user management remains, I'm testing other things. I give you some information which "might" help - please feel free to tell me whether you need more or other infos.
To recap: The problem does only apply to "web users" - the two super users / admins can edit each other. What's special about the web users:
To provide you with more info to make it reproducable for you, have a look at modx_users, modx_users_attributes and modx_user_settings, maybe you can see something which should not be:
SELECT id, username, cachepwd, class_key, active, remote_key, remote_data, hash_class
FROM modx_users
id username cachepwd class_key active remote_key remote_data hash_class 1 Bischof modUser 1 NULL NULL hashing.modPBKDF2 7 andre.bischof@rheinsinn.de modUser 1 NULL NULL hashing.modPBKDF2 6 demo@coaching-evaluationen.de modUser 1 NULL NULL hashing.modPBKDF2 4 eich@stichpro.be modUser 1 NULL NULL hashing.modPBKDF2 8 Bischof2 modUser 1 NULL NULL hashing.modPBKDF2
(users id 1 and 8 are super users)
SELECT * FROM modx_user_attributes
id internalKey fullname email phone mobilephone blocked blockeduntil blockedafter logincount lastlogin thislogin failedlogincount sessionid dob gender address country city state zip fax photo comment website extended 1 1 Haupt-Administrator webmaster@rheinsinn.de 0 0 0 48 1325284509 1325329177 0 0912cdff5979530c6d3336daf27c2659 0 0 {"radar_chart_indizes":" chart_d... 8 8 Zweit-Administrator webmaster@rheinsinn.de 0 0 0 1 0 1324469294 0 78d9b1f1cc997b5cddcdfc146f7c53a2 0 0 [] 4 4 eich@stichpro.be 0 0 0 8 1323356580 1324465209 0 26e1d9a479cdcd3d422e3b644b1c4f37 0 0 {"tabellenband":"var arrdata = [ {nummer:\"A01\", ... 6 6 a.bischof@gmx.net 0 0 0 12 1324566057 1324818677 0 e77b59c180fe6ef432df2a75ee11ae1c 0 0 {"kennzahlen":"\n
Frisco created Redmine issue ID 6491
In modx 2.1.3-pl and 2.1.5-pl super users can't edit "web users" - users, who have restricted rights for a secured area in the web context.
I described that thouroughly here: [[http://forums.modx.com/thread/72710/problem-with-user-management]]
Summary: modx runs under debian 6 (64bit, kernel 2.6.37 in a xen virtual server under lighttpd 1.4.29 with php 5.2.12 and mysql 5.0.51a (client/server), FURLs enabled with alias paths.
Logging in the managers gives a 302 for redirection, resulting in a time lag of about 75secs - all other redirects, i.e. in the web context, are fast and responsive.
By the first attempt to edit a user after logging in modx jumps to the web context, as the manager URL is like: /manager?a=49 (without index.php) instead of /manager/index.php?a=49
and modx jumps to the content page with the id=49
Typing in "/manger" manually solves the problem and modx remains in the mgr context.
I can edit the "web user" then, but the buttons in the upper right corner for saving and so on are missing, and all entries on the first tab (information) and on the third tab (access rights - to which group does the user belong) are empty.
I'd be glad to provide you with more information to track this down and help solving the problem.
Any help is greatly appreciated!
Cheers Frisco