MAXdev - I can't log in to my new site either

MAXdev

MDPro installation - I can't log in to my new site either

jhoiby - Sep 01, 2005 - 05:36 PM
Post subject: I can't log in to my new site either

I've got the same problem listed here by several others: When I try to login as Admin I don't get a login failure, yet when I am sent back to the home page it doesn't look like I'm logged in (the menus don't give me admin options, and the login block is still awaiting my login). One other clue, though, is that it says "0 guests and 1 registered user, you are an anonymous user" in the Now Online block.

My site is at http://dev.drats.org

Based on other tips suggested in these forums I can tell you I have:

1. Cleared the Cookie and Temp Internet Files cache
2. Emptied the Sessions table
3. Added *.drats.org to the Trusted Sites list in I.E.
4. Set Cookie security to low. I.E. accept ALL cookies.
5. Set the Internet Zone security to low.
6. Tried all of the above on another computer with the same results
7. Installed Firefox on the 2nd computer with the same results.
8. Ran Firefox from an X session on the drats.org server with the same results.
9. Tried creating and logging in to a user account, with the same results.
10. As a test, logged in with an incorrect password and received a "Login Failure" notice.
11. Wiped the site directory and dratsdev database and started from scratch, with the same results.
12. Restored the install.php file and install directory, and in desperation used the back button to get back into the install pages and modified some of the admin preferences (site root, etc) to see if that would help.
13. Gave up.

My Client Environment
Windows XP SP2, only a week since clean install
IE 6
All critical updates installed
No firewall active
No antivirus installed
No antispam software installed
Running on a NAT firewalled LAN in a Windows 2003 domain
I'm a Taurus. (A joke!!! C'mon guys, I'm grasping at straws here!)

My Server Environment
Fedora Core 4 fresh install
Yum Update run recently
Server is alinetsrv01.alspire.com
MDPro is running in an apache name-virtual-server environment (dev.drats.org).
Running on a non-firewalled public network with static IP
Running IP tables with default-deny policies in place for non-localhost connections.

MDCheck Results
_VERSIONEPHP 5.0.4
Safe Mode OFF
Safe Mode Exec Dir _NO_VALUE
Session Use Cookies ON
Display Errors OFF
Registrer Globals ON
Php_sapi_name apache2handler
Post Max Size 8M
Open_basedir _NO_VALUE

Installation Steps Taken
1. Installed phpMyAdmin-2.6.3-pl1 in ./phpMyAdmin directory, configured, and tested OK. Created dratsdev db and user.
2. Untarred md1073.tar.gz into the site root directory
3. Untarred MDForum_1.0b3.tar.gz into the site root directory.
4. Set following file permissions per install directions on maxdev.com:
[drats@alinetsrv01 dev]$ chmod -R 666 ./config/*
[drats@alinetsrv01 dev]$ chmod 666 config.php
[drats@alinetsrv01 dev]$ chmod 777 ./config
[drats@alinetsrv01 dev]$ chmod -R 777 ./upload
[drats@alinetsrv01 dev]$ chmod 777 ./images/avatar/personal
[drats@alinetsrv01 dev]$ chmod -Rv 777 ./themes/*/theme.cfg
[drats@alinetsrv01 dev]$ chmod 777 cache/_atcompile
5. Ran http://dev.drats.org/install/mdcheck.php to examine settings
6. Edited /etc/php.ini and set register_globals=On per MDPro install instructions.
7. Ran installer script at http://dev.drats.org/install.php
8. Used the following database settings:
Host: localhost
User: dratsdev
Pass: ********
DB Name: dratsdev
Type: MySQL
9. Used "New Install" option. DB setup appeared successful.
10. Set user "Admin" pass to: "********".
11. Renamed install.php -> ******** and install -> *********
12. ERROR: LOGIN FAILS. No error given, just no login. It still shows I'm logged in as a guest and the login box is still available.

Excerpts From the Install Log
ERROR: Some dir/file settings not correct. Repeat....
:
All directories and files are set correct. MD-Pro can work properly. OK
:
All directories and files are set correct. MD-Pro can work properly. OK
:

Step4: Database Information
Database Host: localhost
Database Username: root
Database Password: ******
Database Name: mdpro
Table Prefix (for Table Sharing): md
Database Type: mysql
Site is for intranet or other local (non-internet) use:

Step5: Change DB information, select New Install/Upgrade
Database Host: localhost
Database Username: dratsdev
Database Password: ******
Database Name: dratsdev
Table Prefix (for Table Sharing): md
Database Type: mysql
Site is for intranet or other local (non-internet) use:

Step5: Change DB information, select New Install/Upgrade
Database Host: localhost
Database Username: dratsdev
Database Password: ******
Database Name: dratsdev
Table Prefix (for Table Sharing): md
Database Type: mysql
Site is for intranet or other local (non-internet) use: 0

Step5: Change DB information, select New Install/Upgrade

Step6: New installation
Create the Database:

Step7: Create the Database
No database made.<br>Tables created:
<lots of lines about table creation deleted from log at this point...>

Step8: Setting Your DB Preferences
Admin Login: Admin
Admin Name: Admin
Admin Password: ******
Admin Email: webmaster@yoursite.com
complete server path:
MD-Pro URL: http://
Upload URL: /upload/rte
Subjects-upload-URL: /upload/sub/
Admin URL: http://www.maxdev.com

Step9: Uploaded Data
md_blocks updated.
<lots of lines about updated tables deleted here...>
complete server path:
MD-Pro URL: http://
Upload URL/upload/rte
Admin Email: none@none.com
Subjects-upload-URL: /upload/rte
Admin URL: http://www.maxdev.com

Step8: Upgrade tables, indizes, fields
config files OK:

Step10: Finish
Admin Login: Admin
Admin Name: Admin
Admin Password: ******
Admin Email: ******@*************
complete server path: /home/drats/httpd/public_html/dev
MD-Pro URL: http://dev.drats.org
Upload URL: /upload/rte
Subjects-upload-URL: /upload/sub/
Admin URL: httpd://dev.drats.org

Step9: Uploaded Data

Note error ('httpd') in Admin URL. I didn't fix this because I didn't think it had anything to do with the problem. Should I fix this right away?

Some issues I wonder about:

1. Should I have a name other than "localhost" for the db server?
2. Is there a dns domain setting in MD-Pro I'm missing somewhere that would be affecting cookie domains?

Sorry about the long post, but I figured it would be better to post as much as possible than waste people's time by requring multiple question/answer posts.

Thanks in advance for any constructive advice!

-James

PeteBest - Sep 01, 2005 - 07:23 PM
Post subject:

OK, well without a doubt this is a cookies/session issue, everything I can possibly suggest to try is already in the search engine, but just a couple of pointers in no particular order of success chance:

1. During the install MD-Pro will have asked if you used an intranet or non-qualified hostname, you should have ticked this box
2. Check the contents of the cookie with a text editor
3. Check the clock on both your server and your pc
4. The 1.0.x series of MD-Pro doesn't officially support php5. We recommend php 4.3.11 still. MD-Pro 1.1 will be php5 compatible, shouldn't be the issue, but as a last resort I'd try changing back
5. Also as last resort try using a packet sniffer to find out what your site is actually kicking out
6. Try accessing the site via the IP address and try again

As for your questions, no localhost is fine, that just uses the IP of the machine where the HTTPD is running. The only DNS option in MD-Pro is the intranet option I mentioned earlier

jhoiby - Sep 01, 2005 - 08:43 PM
Post subject:

Pete, thanks for the fantastically quick reply.

I did a fair amount of research in the forums before posting here, which is why I tried so many cookie setting options.

1.) I just tried a fresh install, this time checking the "intranet" checkbox. It didn't help.
2.) Here's a sample cookie, from about 1:29AM local time (UTC -7). I'm afraid I'll need some help or suggestions for decoding it. Does this look appropriate?:
MDPROSID
g43mul7gtku308hdknfqtsqe17
dev.drats.org/
1024
764656768
29733967
1519859536
29732559
*
3.) The server was only about 80 seconds behind the client PC but I thought I'd be thorough so I synchronized them to within 500ms and it didn't help. Both machine's RTCs are set to local time (UTC -7) and a "date"/"time" command on each displays the correct time, date, and zone.
4.) I saw your PHP5 compatibility warning in other forum posts. I *really* don't want to start messing with PHP and Apache recompiling (I can do it, I'd just like to avoid it if I can), and I like having PHP5 available for other programming projects. I'd like to exhaust other options first. Would turning on PHP error reporting help me determine if the error is related to PHP compatibility?
5.) I can do this, but do you have any recommendations on what to watch for in the packets?
6.) I can't access this site (dev.drats.org) by IP since it's a name virtual server. However to be thorough I changed the default site to the new MD Pro site and tried it via IP. Same login issue.

I'll do another pass through the forums and documentation again tomorrow to see what else I might have overlooked. Thanks again for your help!

dmiranda - Sep 01, 2005 - 10:24 PM
Post subject:

Just to double check: do you have zone alarm installed? Even if inactive, the last versions of ZA disrupt localhost.

jhoiby - Sep 02, 2005 - 03:09 AM
Post subject:

Nope. No third-party firewalls installed, and Windows firewall disabled.

I'm guessing it really has to be something server side, since I'm getting the same issue on a 2nd computer with Firefox. But, I've been wrong before...

PeteBest - Sep 02, 2005 - 03:11 AM
Post subject:

jhoiby wrote:

Does this look appropriate?:
MDPROSID
g43mul7gtku308hdknfqtsqe17
dev.drats.org/

This is the only bit that should really make much difference. As long as the g43 line (pn_sessid in the md_sessions db table) matches up with your userid in the md_sessions db table it's fine

jhoiby wrote:

4.) I saw your PHP5 compatibility warning in other forum posts. I *really* don't want to start messing with PHP and Apache recompiling (I can do it, I'd just like to avoid it if I can), and I like having PHP5 available for other programming projects. I'd like to exhaust other options first.

Fair enough, like I said before it works OK for me. That's not to say it will work that well for everyone, and we don't support it, so basically if we can't get it working it's tough

jhoiby wrote:

Would turning on PHP error reporting help me determine if the error is related to PHP compatibility?

doubtful, you can give it a go though

jhoiby wrote:

5.) I can do this, but do you have any recommendations on what to watch for in the packets?

Nope, never had the need to do it. Google is your friend Wink

jhoiby wrote:

6.) I can't access this site (dev.drats.org) by IP since it's a name virtual server. However to be thorough I changed the default site to the new MD Pro site and tried it via IP. Same login issue.

I've never had any dealings with virtual server setups, so I can't give any advice about this

Attached is a .zip file with my phpinfo on my localhost setup with php 5.0.4. Recommend you check the sessions section and see if there's any differences to your configuration

jhoiby - Sep 02, 2005 - 02:16 PM
Post subject: Found it!!!! HTTP_GET_VARS problem.

Your talk about sessions got me thinking that it had to be something along those lines. I finally got smart and looked in the apache error logs and saw the following:

PHP Notice: Undefined variable: HTTP_GET_VARS in /var/www/html/javascript/openwindow.php on line 25, referer: http://alinetsrv01.alspire.com/index.php

So, I went into php.ini and set:

register_long_arrays = On

And that did the trick. It turns out it was a PHP5 related issue (HTTP_GET_VARS is no longer available by default in PHP5), but an easily surmountable one. Without all your hints about checking session settings it would have taken me a long time to find the problem. Thanks again for your quick response! I look forward to being able to contribute back to the MDPro community in some way in the future. Hopefully this thread will help others struggling with the same issues as well!

Flerbizky - Mar 28, 2006 - 02:29 AM
Post subject:

Yes baby !... Thank you very much - had this exact same problem...

Cheers,
Steff

manuelq2 - Nov 11, 2006 - 11:32 AM
Post subject:

Same problem

::Same solution Dancing

Quote:

register_long_arrays = On

TKZ., very much guys.

Rajven - May 13, 2007 - 04:31 AM
Post subject:

So, if i can't modify my php.ini, i'm disgraced? .___.

MDMods.com - May 13, 2007 - 05:40 AM
Post subject:

MDLite shouldn't have this problem as it mainly uses short arrays. I did notice some long arrays have crept back into being used with 1.0.80, not sure about 1.0.81 yet

That said, by default php has register_long_arrays enabled. I have no idea why your host would change it unless they haven't got a clue what they're doing.

You could always try the following line in your .htaccess file

Code:

php_flag register_long_arrays On

Then check your phpinfo again to see if the local value has changed

Rajven - May 13, 2007 - 10:40 PM
Post subject:

Thank you! I'll try and see if it works Smile

Rajven - May 14, 2007 - 01:15 AM
Post subject:

IT WORKS!! I setted a .htaccess file and even the modify in not figured in the infophp the cms works properly!

I hope these method goes right with you too!

Bye and thanks

cdfranck - May 23, 2007 - 10:27 AM
Post subject: same issue

If I add an htaccess file with only the register long arrays directive I get a 500 error. Adding a php.ini file doesn't seem to do anything.

PHP 5.2.1 info...
System Linux infong 2.4 #1 SMP Tue May 23 17:47:33 CEST 2006 i686 unknown
Build Date Feb 12 2007 16:31:26
Configure Command ../configure --program-suffix=5 --with-pear=/usr/local/lib/php5 --with-config-file-path=/usr/local/lib/php5 --with-libxml-dir=/usr/local/php5 --without-sqlite --with-mysqli=/usr/local/mysql/bin/mysql_config --enable-soap --with-xsl=/usr/local/php5 --enable-mbstring=all --with-curl=/usr/local/php5 --with-mcrypt=/usr/local/php5 --with-gd --with-pdo-mysql=/usr/local/mysql --with-freetype-dir --with-libxml-dir=/usr/local/php5 --with-mysql=/usr/local/mysql --with-zlib --enable-debug=no --enable-safe-mode=no --enable-discard-path=no --with-png-dir=/usr/lib --enable-track-vars --with-db --with-gdbm --enable-force-cgi-redirect --with-ttf=/usr/ --enable-ftp --enable-dbase --enable-memory-limit --enable-calendar --enable-wddx --with-jpeg-dir=/usr/src/kundenserver/jpeg-6b --enable-bcmath --enable-gd-imgstrttf --enable-shmop --enable-mhash --with-mhash=/usr/src/kundenserver/mhash-0.8.9/ --with-openssl --enable-xslt --with-xslt-sablot --with-dom --with-dom-xslt --with-dom-exslt --with-imap --with-iconv=/usr/local --with-bz2 --with-gettext --enable-exif --with-idn
Server API CGI
Virtual Directory Support disabled
Configuration File (php.ini) Path /usr/local/lib/php5/php.ini
PHP API 20041225
PHP Extension 20060613
Zend Extension 220060519
Debug Build no
Thread Safety disabled
Zend Memory Manager enabled
IPv6 Support enabled
Registered PHP Streams php, file, data, http, ftp, compress.bzip2, compress.zlib, https, ftps
Registered Stream Socket Transports tcp, udp, unix, udg, ssl, sslv3, sslv2, tls
Registered Stream Filters string.rot13, string.toupper, string.tolower, string.strip_tags, convert.*, consumed, convert.iconv.*, bzip2.*, zlib.*

thewarden - Aug 20, 2007 - 01:57 AM
Post subject: Re: same issue

cdfranck wrote:

If I add an htaccess file with only the register long arrays directive I get a 500 error. Adding a php.ini file doesn't seem to do anything.

Same here. I've been using mdpro for years without this problem. Suddenly now, I can not login. It's driving me nuts. I've completely emptied my sessions table (which mdsos would not do btw), cleared my cookies and cache, and still can't get in. Even from my laptop. I don't think anyone can login from anywhere at the moment.

What else can we do??? I don't understand why it just started doing this. It makes no sense to me.

TiMax - Aug 20, 2007 - 02:20 PM
Post subject:

Thewarden ... witch MDro version ? php version ? mysql version ? apache version ? .... please give us info's

If it is MDPro 1.08x try to execute this sql query

Code:

DROP TABLE IF EXISTS `md_session_info`;
CREATE TABLE `md_session_info` (
`pn_sessid` varchar(32) NOT NULL default '',
`pn_ipaddr` varchar(20) NOT NULL default '',
`pn_firstused` int(11) NOT NULL default '0',
`pn_lastused` int(11) NOT NULL default '0',
`pn_uid` int(11) NOT NULL default '0',
`pn_vars` blob,
`pn_antispider` varchar(64) NOT NULL default '',
PRIMARY KEY (`pn_sessid`),
KEY `idx_last` (`pn_lastused`),
KEY `pn_antispider` (`pn_antispider`)
);

thewarden - Aug 20, 2007 - 02:31 PM
Post subject:

mdpro 1.0.76

Apache version 1.3.37 (Unix)
PHP version 5.2.2
MySQL version 4.1.22-standard
Architecture x86_64
Operating system Linux
Kernel version 2.6.19.2-grsec-Nett

TiMax - Aug 21, 2007 - 03:43 AM
Post subject:

sorry mdpro 1.0.76 is not supported anymore, it is too old, you MUST upgrade ASAP

thewarden - Aug 22, 2007 - 07:02 AM
Post subject:

I wish it were that easy. Reason I haven't, is cuz everytime I try, something goes wrong. Now, when I follow the instructions for upgrading from 1.0.76 step by step, during the upgrade installation process, somewhere it goes right back to the beginning. When I follow through the second time, it stops and says, "md_modules updated.error Duplicate column name 'pn_gid'" This is the 3rd attempt at upgrading and it never goes smoothly which is why I've been sticking with what worked.

thewarden - Aug 22, 2007 - 07:13 AM
Post subject:

So I did a new install of md lite 1.0.81, and I still can't login right. It logs me in, but only until I hit a link, then I'm logged out again. Must be an issue with my server, but I've never had it happen before. Any suggestions?

thewarden - Aug 22, 2007 - 07:17 AM
Post subject:

Never mind. My dumb mistake. Forgot to delete my cookies. It appears to be keeping me logged in right now. But I've a lot of work to do! Smile

cbradley - Nov 28, 2007 - 04:39 AM
Post subject:

This may be of help.

I had login problems with MDP 1.076 after my host upgraded to PHP5. We couldn't upgrade to MDLite cos it lacks some vital modules. Problems continued even after we reverted to PHP4, presumably because the PHP4 setup had been changed during the upgrade.

First attempt was enabling register_globals. That allowed us to log in but host commented:

Quote:

I have enabled PHP4 and register_globals is now On for you. I can't however stay logged in. I must be logged in but I get told I don't have authorisation.

The solution, which allows the old installation to work perfectly with PHP 5 involved a small code hack (solution thanks to our host):

Add this:

Code:

if (version_compare(phpversion(), '5.2.0', '>=')) {
register_shutdown_function('session_write_close');

at line 90 of the file: /home/celshar/public_html/mdp/includes/
pnSession.php

then clear the sessions table in the database + cookies.

All now working fine with PHP5

cdphreaker - Apr 16, 2008 - 02:49 PM
Post subject:

I am having the exact same problem. Since i've heavily modded the files i can't upgrade to newer files either. But how come all of a sudden the site shuts down the login?? Have tried the .htaccess which gives me a Error 500, also emptied the session tables but still no solution. I tried putting a php.ini in the root directory with the register_long_arrays On parameter too but then also it won't do anything about it. If anyone could give me any insight about it. I can't shut down the site and i'm under great pressure to get it up and running again otherwise 2yrs of continuous work will get wasted. Please help me out.

TiMax - Apr 16, 2008 - 03:34 PM
Post subject:

you version is not more supported, sorry but you MUST upgrade that's it that's all Smile

cdphreaker - Apr 16, 2008 - 05:05 PM
Post subject:

Well Tim i do understand what you are suggesting. But, there should be a solution to it right? I mean if i upgrade then i might have to modify about 60 odd files again which is not practical for me. I appreciate your point in telling me to upgrade to keep up the security features in the website but still....i can't understand why the site just shut me out. When it was working perfectly till last week. I hope you do understand my problem. Kindly tell me what else i can do about it. Thanks in advance.

All times are GMT + 13 Hours
Powered by MDForum 2.0.8 © 2003-2007 based on phpBB © 2001, 2002 phpBB Team
and by MDRebel which uses Theme Graphics by Daz
and by Attachment-Mod 2.4.3