Status
Not open for further replies.

Nirjonadda

Customer
Hello
We have sucessfully transferred our website to new server now get one problem,Administrator second password not work,How to fix is issue ?
 
Please be more specific than "not work". I cannot help you solve this issue without more information.
 
In Administrator Security when i set admin additional password to log in than i get popup login page , when i put user and password than hit logon , cannot login get popup login page again !
 
Are you sure they are entering the username and password correctly? Have you tried resetting their passwords via the Administrator Security panel?

Also, does your PHP have safe mode enabled?
 
PHP's safe mode is off , yes I put username and password correct , but we get this issue when moved my site to new server,
 
Is your server running as Apache module or CGI?

If you go to your PHP Info page and look at the "Server API", if it's Apache Module it will say "Apache 2.0 Handler" and if it's CGI it will say something like "CGI/FastCGI".

If it's running as CGI, unfortunately this won't work - for the same reason vB Optimise's opcode cachers won't work: CGI doesn't properly carry data between sessions per-user.
 
I've never tested it with LiteSpeed so I couldn't say whether it works with that unfortunately :(
 
If you were to disable Litespeed and go back to Apache (there should be a switch for that if you're using a WHM/cPanel-based host), and use the "DSO" method for loading PHP into Apache, does it work then?
 
Is your server running as Apache module or CGI?

If you go to your PHP Info page and look at the "Server API", if it's Apache Module it will say "Apache 2.0 Handler" and if it's CGI it will say something like "CGI/FastCGI".

If it's running as CGI, unfortunately this won't work - for the same reason vB Optimise's opcode cachers won't work: CGI doesn't properly carry data between sessions per-user.

Is this still an issue? I just purchased this mod exactly for this. Now I won't be able to use it? My server is running CGI. And now finally I understand why my vbOptimise is also not working properly!
 
Unfortunately this is a limitation in PHP itself, it's not something we can work around :(
 
You may have some problems with permissions if you do so - DSO runs with PHP as nobody, so if you're using phpSuExec or something similar that causes PHP-generated files to be written as the same user as your Apache user, then you're going to have major problems switching.

To check this, simply open up your /dbtech/vbshout/aop folder. Are the text files there created with the same UID and Group (you may need to enable these columns in your FTP app by right clicking the column header) as files you manually uploaded?
 
You may have some problems with permissions if you do so - DSO runs with PHP as nobody, so if you're using phpSuExec or something similar that causes PHP-generated files to be written as the same user as your Apache user, then you're going to have major problems switching.

To check this, simply open up your /dbtech/vbshout/aop folder. Are the text files there created with the same UID and Group (you may need to enable these columns in your FTP app by right clicking the column header) as files you manually uploaded?

Yes, it looks like it.

Capture.webp

So I guess switching is perhaps not such a good idea then?

Thanks.
 
You would need to change the owner/group on all files like that to 99/99 - and neither one of us would know how many files and where they are.

It's probably a very bad idea unless you feel like dealing with random "no permissions" or "file access denied" errors for days or weeks. We had to deal with it due to the security implications of using SuExec, but it was not a procedure we're anxious to repeat or undo.

If you're curious, the security implication is that if a shell script is uploaded, they will have the ability to modify all your PHP files and inject additional exploit code, making it much harder to detect.
 
Everything listed in this thread, i.e. the permissions issues :p

If your site is well established you probably shouldn't switch, unless you have a very good reason for doing so.
 
Correct, a control panel provided .htaccess login is better and will work with all PHP types :)
 
Ok easy enough. Maybe have the mod detect if the server is using fastcgi and if so have an option instead to create the .htaccess file. It might make it easier for some users, but regardless it should detect if I am using FastCGI and not let me lock myself out.
 
Status
Not open for further replies.

Legacy vBSecurity

vBulletin 3.8.x vBulletin 4.x.x
Seller
DragonByte Technologies
Release date
Last update
Total downloads
815
Customer rating
0.00 star(s) 0 ratings
Back
Top