
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| WoW Raid Manager :: Forums :: Closed Support Questions | |||
|
|||
No access to configuration after installGo to page >> |
| Author | Post |
| Gwynwyffar |
| ||
![]() Joined: Fri Mar 21 2008, 12:36PM Posts: 17 | I just did a fresh install of WoW Raid Manager on my website using the e107 authentication (since the main part of my site is run by e107). I am the Main Site Admin for e107 and set my login as the admin login for WoWRM, but when I log in, I see no link to the Configuration in the left menu of WoWRM. The phpraid tables are within my e107 database and the install appeared to go just fine. Any ideas? Oh- I also set No Restrictions for the minimum class to log into phpraid. [ Edited Mon Mar 24 2008, 11:24AM ] | ||
| Back to top |
| Illydth |
| ||
![]() ![]() Joined: Mon Sep 24 2007, 02:51PM Posts: 1886 | Ok, that's a bit strange, it sounds as if the userclass didn't get set properly upon install. If you have something like phpMyAdmin or access to your database in some way could you run me the following query and let me know it's results: SELECT * FROM `phpraid_permissions` And SELECT * FROM `phpraid_profile` If you'd prefer not to post the second select (there will be an MD5 password that is reverseable...my recommendation is NOT to post this, or at least blank out the password) what I'm looking for on the second one is to see if the "priv" column is set to the same value as the privlidge for super admin in the first query (should be 1) on your admin ID. Also make sure that the username is the same username as your admin ID on e107 Let me know the answers so that we can get this one knocked out. --Illydth - Douglas Wagner - Site Admin | ||
| Back to top |
| Gwynwyffar |
| ||
![]() Joined: Fri Mar 21 2008, 12:36PM Posts: 17 | first query- permission_id name description announcements configuration guilds locations permissions profile raids logs users 1 phpRaid Superadmin Full access 1 1 1 1 1 1 1 1 1 second query- Generated by: phpMyAdmin 2.11.5 / MySQL 5.0.45-log SQL query: SELECT * FROM `phpraid_profile` LIMIT 0, 30 ; Rows: 4 profile_id email password priv username 1 gwynwyffar@xxxxxxxxxx.com junkpass 1 elowynn 2 3 4 There was no MD5 password, the word 'junkpass' you see above is exactly what appears in the database however that is not my e107 password. I did alter the email address I posted above, though. Should I try dumping all the phpraid tables and re-installing? | ||
| Back to top |
| Illydth |
| ||
![]() ![]() Joined: Mon Sep 24 2007, 02:51PM Posts: 1886 | The fact you have "junkpass" in there kinda bugs me. When you install the application it prompts for username and e-mail address and adds a profile to the admin table for that user/email. Note it does NOT authenticate the user against e107 or validate that the user properly exists...I must have been lazy when writing this. After installation you have an admin profile with a user in your database and his or her password is "junkpass" since we never prompted for a password upon installation. This is where you are currently. The next step then is that the user goes back and authenticates to the system via the user ID and password of their E107 database. The user/password is taken into the e107 tables and a check on username and password match is made. If the username and password match, the e-mail address and current e107 password are yanked from the e107 tables and the profile is updated. What this means is, if you have successfully logged into the system the first time, the password on admin user SHOULD NOT be junkpass. The only possible way for that to happen is if you did not log in or if you failed to log in. The check is simple: $username == strtolower($data['user_loginname']) && $password == $data['user_password'] where $password has already been encrypted by the md5 function. The end result here is that either your username you input didn't match the username stored in the e107 table (username typed in vs usernane on the e107 users table) or the password you typed in, after being MD5'd didn't match the password returned from the selection of the username/password from e107. However if that happens, "0" is returned to the calling function and you should get: if($logged_in == 0) { $errorTitle = $phprlang['login_title']; $errorMsg = $phprlang['login_msg']; $errorDie = 1; } which basically means "hey you failed to log in." The ONLY other explination I can give you at this point is that you haven't attempted to log in after the installation. All the permissions are set right, everything is valid for that profile...it's a login issue. --Illydth - Douglas Wagner - Site Admin | ||
| Back to top |
| Gwynwyffar |
| ||
![]() Joined: Fri Mar 21 2008, 12:36PM Posts: 17 | I did log in successfully, at least I received no errors. I entered my e107 username and e107 password and then phpraid showed me logged in successfully. I ran those database queries you requested after having logged in multiple times. I had even tried closing the browser, and then re-logging in to make sure the cookies had been reset. Here's a screenshot of what it looks like after I've logged in: Image: http://silent-strike.org/avatars/phpraid.jpg | ||
| Back to top |
| Illydth |
| ||
![]() ![]() Joined: Mon Sep 24 2007, 02:51PM Posts: 1886 | Hum, ok. Looks like I need to load up a copy of e107 and test this one out for myself. There was a bug in phpBB2, no reason that e107 isn't borked also.:) Give me a while to look at this, and thanks for the report. :) --Illydth - Douglas Wagner - Site Admin | ||
| Back to top |
| Gwynwyffar |
| ||
![]() Joined: Fri Mar 21 2008, 12:36PM Posts: 17 | Thanks for your quick attention. Let me know if there's any more information I can provide you with that might help. | ||
| Back to top |
| Illydth |
| ||
![]() ![]() Joined: Mon Sep 24 2007, 02:51PM Posts: 1886 | Don't know what's going on with your install, I just did a fresh installation of both e107 and WRM and am not seeing any issues. Ok, first, I'll stand corrected on the "junkpass" thing, that will only ever get updated if the user's e-mail address changes in e107...wow, this auth code is craptacular, I wonder what moron wrote this e107 auth system....good lord he should be shot! Oh Wait...that'd be me... Anyway, so assuming you've typed in your e-mail address correctly on the admin user junkpass is what you can expect. Ok, so what this is looking like to me is that the code isn't recognizing the permissions values. Your DB tells it that your user is superuser and that superuser has all the proper rights and privs, but for some reason the system isn't connecting the two. My recommendation at this point is to drop the WRM tables out of your e107 installation (They ARE in the same database as your e107 tables right? Generally you SHOULD get an error if you try anything else), delete your phpRaid directory and re-upload all files, making sure to overwrite if you have the option (though if you have all your files deleted it shouldn't prompt you). Once you have a completely new installation, go ahead and try re-installing to your e107 database and let me know what happens. If this doesn't work I may provide you a special file or two with some debug information in it to see what's going on. --Illydth - Douglas Wagner - Site Admin | ||
| Back to top |
| Gwynwyffar |
| ||
![]() Joined: Fri Mar 21 2008, 12:36PM Posts: 17 | Dumped tables, deleted files, and did fresh install, still the same problem. I can log in, but cannot access configuration. I also had another of the site's admins log in. This person is not Super Admin but is set as an Admin in e107 terms and he could not access configuration either. If it helps the ranks of permissions on the e107 site are Site Admin (created when the site is installed), Admin, and then we have various permissions for Officer, Striker, and Initiate. I don't know if it matters or not, but there are 2 Site Admins in my e107 install, so there are 2 people with total access to the site, neither of which can access configuration in phpraid. [ Edited Mon Mar 24 2008, 05:29PM ] | ||
| Back to top |
| Illydth |
| ||
![]() ![]() Joined: Mon Sep 24 2007, 02:51PM Posts: 1886 | Check. I'm working a few other issues, i'll make this a priority as soon as I can. - Douglas Wagner - Site Admin | ||
| Back to top |
| Illydth |
| ||
![]() ![]() Joined: Mon Sep 24 2007, 02:51PM Posts: 1886 | You're not forgotten, i'm working a cross linked database issue at the moment, your's is next up in the queue. - Douglas Wagner - Site Admin | ||
| Back to top |
| Illydth |
| ||
![]() ![]() Joined: Mon Sep 24 2007, 02:51PM Posts: 1886 | Ok, so looking at it, login isn't the issue. You are properly logged in. Permissions isn't the issue either, the database is properly storing you as having admin permissions (true across the board). So, at this point it's likely that there's some piece of code that is either exchanging your user for another user or dropping the variable that's giving you permissions access. What bothers me is that, again, i'm not seeing it and can't re-produce it so i'm flying blind on this one. The code for displaying your menu is pretty simple, so we're going to check permissions. I'd like you to upload the attached file to your webserver. BACK UP YOUR OLD ONE FIRST! You'll restore it in a second. Download the file attached here and unzip/upload to the includes directory of your WRM installation. This is a debug file. It will print a bunch of lines in black text above your WRM screen when you load the initial page (any page actually). I'd like you to load your front page, log out, log in and then cut/paste what the printout is. NOTES * This will appear pretty much INVISIBLE if you are using the default theme (it'll be black text on black). Just highlight from the upper left corner of your browser and drag down and you'll see the lines as they get highlighted, I only need the text output above the graphic, not the whole screen, and a screenshot will not do me any good since the text is hidden. * THIS WILL LOOK LIKE IT HOSES UP YOUR OUTPUT. Text will appear huge, things will look just off. Don't worry about it, this is why you backed up your previous file. Just log out, log in, cut me the text and then remove the file you uploaded and replace with the one you backed up, this will bring everything back to normal again and give me the info I need to continue looking at this. --Illydth page_header.zip [/html][ Edited Thu Mar 27 2008, 07:27PM ] - Douglas Wagner - Site Admin | ||
| Back to top |
| Gwynwyffar |
| ||
![]() Joined: Fri Mar 21 2008, 12:36PM Posts: 17 | On initial Load: Priv_Announcement: 0 Priv_Config: 0 Priv_Guilds: 0 Priv_Locations: 0 Priv_Logs: 0 Priv_Permissions: 0 Priv_Profile: 0 Priv_Raids: 0 Priv_Users: 0 After Logging in: Priv_Announcement: 0 Priv_Config: 0 Priv_Guilds: 0 Priv_Locations: 0 Priv_Logs: 0 Priv_Permissions: 0 Priv_Profile: 0 Priv_Raids: 0 Priv_Users: 0 After Logging out: Priv_Announcement: 0 Priv_Config: 0 Priv_Guilds: 0 Priv_Locations: 0 Priv_Logs: 0 Priv_Permissions: 0 Priv_Profile: 0 Priv_Raids: 0 Priv_Users: 0 | ||
| Back to top |
| Illydth |
| ||
![]() ![]() Joined: Mon Sep 24 2007, 02:51PM Posts: 1886 | Well now THAT makes some sense. Now I just need to figure out why even though the database says you are privileged the session says you're not. - Douglas Wagner - Site Admin | ||
| Back to top |
| Illydth |
| ||
![]() ![]() Joined: Mon Sep 24 2007, 02:51PM Posts: 1886 | Ok, one more file for you to upload and try for me. I don't need the prior one enabled. This is where the privileges are loaded from the database. Same as before backup the old includes/functions_auth.php, upload this file (this time to your includes directory over the old functions_auth.php) and log out, log in, etc. This should print ALOT more (including some SQLs and such) to see what exactly is going on. Hopefully by the end of this one I know what's going wrong. BTW I apologize for having to have you do Debug on your own site but there's SOMETHING going on with your site that no one else is seeing. --Illydth functions_auth.zip- Douglas Wagner - Site Admin | ||
| Back to top |
| Gwynwyffar |
| ||
![]() Joined: Fri Mar 21 2008, 12:36PM Posts: 17 | On initial load: Session PID: -1 Profile_ID: -1 Profile Get SQL: SELECT * FROM phpraid_profile WHERE profile_id='-1' Priv from Profile Table: Priv Get SQL: SELECT * FROM phpraid_permissions WHERE permission_id='' Announcements: Configuration: Profile Guilds Locations Logs Raids Users Permissions After logging in: Session PID: -1 Profile_ID: -1 Profile Get SQL: SELECT * FROM phpraid_profile WHERE profile_id='-1' Priv from Profile Table: Priv Get SQL: SELECT * FROM phpraid_permissions WHERE permission_id='' Announcements: Configuration: Profile Guilds Locations Logs Raids Users Permissions Warning: Cannot modify header information - headers already sent by (output started at /usr/www/users/pl450/phpraid/includes/functions_auth.php:54) in /usr/www/users/pl450/phpraid/auth/auth_e107.php on line 78 Warning: Cannot modify header information - headers already sent by (output started at /usr/www/users/pl450/phpraid/includes/functions_auth.php:54) in /usr/www/users/pl450/phpraid/auth/auth_e107.php on line 79 Warning: Cannot modify header information - headers already sent by (output started at /usr/www/users/pl450/phpraid/includes/functions_auth.php:54) in /usr/www/users/pl450/phpraid/login.php on line 57 After logging out: Session PID: 63 Profile_ID: 63 Profile Get SQL: SELECT * FROM phpraid_profile WHERE profile_id='63' Priv from Profile Table: Priv Get SQL: SELECT * FROM phpraid_permissions WHERE permission_id='' Announcements: Configuration: Profile Guilds Locations Logs Raids Users Permissions Warning: Cannot modify header information - headers already sent by (output started at /usr/www/users/pl450/phpraid/includes/functions_auth.php:54) in /usr/www/users/pl450/phpraid/auth/auth_e107.php on line 126 Warning: Cannot modify header information - headers already sent by (output started at /usr/www/users/pl450/phpraid/includes/functions_auth.php:54) in /usr/www/users/pl450/phpraid/auth/auth_e107.php on line 127 Warning: Cannot modify header information - headers already sent by (output started at /usr/www/users/pl450/phpraid/includes/functions_auth.php:54) in /usr/www/users/pl450/phpraid/login.php on line 68 And don't worry about asking me to debug. I really appreciate all the time and effort you're putting in to get one site working! Thanks so much for all the help. | ||
| Back to top |
| Illydth |
| ||
![]() ![]() Joined: Mon Sep 24 2007, 02:51PM Posts: 1886 | Oh my. Something is TOTALLY wrong. Profile ID -1?!?!? This explains why you're getting what you're getting. You are getting a profile ID that doesn't exist in the database. When the code goes to pull your permissions, your profile ID doesn't exist in the database and returns a blank. From there you get nothing. So the next order of business is to figure out why upon logging in you get a -1 profile ID but upon logging out you get a 63 for profile ID...Something REALLY strange. --Derex - Douglas Wagner - Site Admin | ||
| Back to top |
| Illydth |
| ||
![]() ![]() Joined: Mon Sep 24 2007, 02:51PM Posts: 1886 | Ok. Yet another item for you to upload. This one goes in your auth folder. Don't need your other stuff enabled so you can restore both of the other two's backups. Same stuff here, back up first, upload over the top, run login , logout, let me know what prints. --Derex auth_e107.zip- Douglas Wagner - Site Admin | ||
| Back to top |
| Gwynwyffar |
| ||
![]() Joined: Fri Mar 21 2008, 12:36PM Posts: 17 | On initial load: session_start Called to initialize Session, THIS IS A PROBLEM. Warning: session_regenerate_id() [function.session-regenerate-id]: Cannot regenerate session id - headers already sent in /usr/www/users/pl450/phpraid/auth/auth_e107.php on line 158 On Log In: session_start Called to initialize Session, THIS IS A PROBLEM.POST: USERNAME SET Username from Post: elowynn Password after MD5 from Post (TRAPPED AND REMOVED BY ADMIN) e107 Table Prefix: e107_ SQL For User Table: SELECT user_id, user_loginname, user_password, user_email, user_class FROM e107_user Processing: : User ID: 62 Processing: : User ID: 63 Username/Password Match, Login In Progress. Warning: Cannot modify header information - headers already sent by (output started at /usr/www/users/pl450/phpraid/auth/auth_e107.php:152) in /usr/www/users/pl450/phpraid/auth/auth_e107.php on line 89 Warning: Cannot modify header information - headers already sent by (output started at /usr/www/users/pl450/phpraid/auth/auth_e107.php:152) in /usr/www/users/pl450/phpraid/auth/auth_e107.php on line 90 Store->Session: Loginname: elowynn Store->Session: Logged IN = 1 Store->Session: Profile_ID: 63 Session: username: elowynn Session: Profile_ID: 63 Session: Profile_ID: 63 Profile ID from Profile Table: 1 Session: Profile_ID: 63 Profile ID from Profile Table: 2 Session: Profile_ID: 63 Profile ID from Profile Table: 3 Session: Profile_ID: 63 Profile ID from Profile Table: 4 Session: Profile_ID: 63 Profile ID from Profile Table: 5 Session: Profile_ID: 63 Profile ID from Profile Table: 6 Session: Profile_ID: 63 Profile ID from Profile Table: 7 Session: Profile_ID: 63 Profile ID from Profile Table: 8 Session: Profile_ID: 63 Profile ID from Profile Table: 9 Session: Profile_ID: 63 Profile ID from Profile Table: 10 Session: Profile_ID: 63 Profile ID from Profile Table: 11 Session: Profile_ID: 63 Profile ID from Profile Table: 12 Session: Profile_ID: 63 Profile ID from Profile Table: 13 Session: Profile_ID: 63 Profile ID from Profile Table: 14 Session: Profile_ID: 63 Profile ID from Profile Table: 15 Session: Profile_ID: 63 Profile ID from Profile Table: 16 Session: Profile_ID: 63 Profile ID from Profile Table: 17 Session: Profile_ID: 63 Profile ID from Profile Table: 18 Warning: Cannot modify header information - headers already sent by (output started at /usr/www/users/pl450/phpraid/auth/auth_e107.php:152) in /usr/www/users/pl450/phpraid/login.php on line 57 On Log out: session_start Called to initialize Session, THIS IS A PROBLEM. Warning: Cannot modify header information - headers already sent by (output started at /usr/www/users/pl450/phpraid/auth/auth_e107.php:152) in /usr/www/users/pl450/phpraid/auth/auth_e107.php on line 145 Warning: Cannot modify header information - headers already sent by (output started at /usr/www/users/pl450/phpraid/auth/auth_e107.php:152) in /usr/www/users/pl450/phpraid/auth/auth_e107.php on line 146 Warning: Cannot modify header information - headers already sent by (output started at /usr/www/users/pl450/phpraid/auth/auth_e107.php:152) in /usr/www/users/pl450/phpraid/login.php on line 68 [ Edited Mon Mar 31 2008, 10:13AM ] | ||
| Back to top |
| Illydth |
| ||
![]() ![]() Joined: Mon Sep 24 2007, 02:51PM Posts: 1886 | WOW ok, we have 2 problems here. Thankfully i've identified both. We're not far from complete on this. The first issue is that your proper account isn't getting created upon initial installation of the software. Here's what's happening with that: // Insert a value for the Admin Profile. In the "Done" function of the e107 installation we run the above query. After you've been verified in the e107 database we need to create a profile in the WRM database to match you up. Note what the SQL Inserts: Profile_ID: 0 EMail: (input e-mail) Password: (input password) (Generally junkpass) Privlidges: 1 Username: (input Username) Note Profile_ID = 0. The Profile_ID field on this table is an autonumber, meaning that when you do this upon initial installation you get Profile ID 1 inserted into the table (which as you can see from your WRM Profile Table, is exactly where your elowynn user is created). But look again at your e107 profile ID... ELOWYNN's e107 PROFILE ID IS NOT 1, it's 63...major bug in the e107 connector. The reason this is working for 90% of the population out there is becasue in almost every case, the FIRST created e107 user was the admin user, and in most cases "site admin" has never changed hands. What this means is that by happy circumstance for MOST e107 installations profile ID 1 and e107 User ID 1 just HAPPEN to be the same person. Also by circumstance, the dude that is site admin for e107 is GENERALLY the dude installing WRM and setting up the admin account there. Thus, for most people, circumstances and happenstances coinside to make their e107 / WRM installs work properly. YOU on the other hand have a website were your WRM admin != The first Created user in e107, thus you have the problem. This is a fairly easy fix and i'll get that done soon enough. ****** HOWEVER ****** This leaves us a second problem to solve. When Login goes through and authenticates with the e107 tables it recognizes you as a proper user. It correctly selects your profile ID and goes through the process of trying to find your user. If you look at your output starting after the "Session->Store" outputs you see a loop on ProfileID where it pritns: Profile ID from Profile Table: Session Profile_ID: This is looping through all the currently existing users in the WRM Profile table looking for a match to your Profile ID (GOD this code sucks, WHERE clause FTW!). As we see from above, it's NOT going to find it. (WORSE yet, if you happened to have 63 users the login would now OVERWRITE user 63 with your e-mail address since it would find a matching Profile ID). Where our next problem comes in to solve is that after it goes through this loop and doesn't find your user, it does the following: $sql = sprintf("INSERT INTO " . $phpraid_config['db_prefix'] . "profile VALUES ('$s', '$s', '$s', '$s', '$s')",In other words, it tries to dump your new user into the WRM Profile table and create a new profile. In your case it's not doing that. It SHOULD have created a profile 63 for you and the next time you logged in you should be logged in with your elowynn user (however as a NORMAL user, not as an admin). Unfortunately, in your case, it doesn't seem to be doing that. At all points it seems to be failing the insert WITHOUT tripping the print_error. Attached is a new e107_auth.php file (same as the last one) this time i'm additionally printing out the final SQL statement that does the insert. My "Guess" is that there are additional ' around the input information that weren't there in 3.1.2 (Note that the $s's in the SQL all have ' ' around them, however I believe that sprintf does this "by default" as i've removed these in most other cases in the code). This would explain why 3.1.2 is working for most people. Anyone out there having a problem with new users being created in the WRM software? Regardless, please upload the file, run it, let me know the output and i'll see what I can do to fix both of these issues post haste. --Illydth auth_e107.zip- Douglas Wagner - Site Admin | ||
| Back to top |
| Moderators: Illydth |