Cant Login to Admin after fresh Setup

The first 'unable to load' means that your Apache/PHP is not built correctly or at the very least the php.ini needs rectification.

The version test is pretty certainly reporting an issue as all it does is get the version from PHP_VERSION and make sure it is v5.3.0+ .. There is also an updated version on github with a few more tests.

Good luck!

Thanks for speedy response.
I just grabbed the expanded requirements check script from github and will both give it a try and forward latest info and script to my web host tech support.

Hope they fix it quickly for you, I am toying with crowd funding an enhanced version of the checker that will do aMember/Wordpress with an option to download the scan results.

My latest results of CLI run of the advanced check script (with my user login obfuscated as before...)

I have just posted the advanced script and my results to my web hoster support site. (they too are in significantly different time zone than me, so as with Amember Support, there will be some time lag.)
I acknowledge that I don't know anything about most of the listed modules ... oh well ...

[xxxxxxxx@cp ~]$ php requirements.php
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/mysql.so' - libmysqlclient.so.15: cannot open shared object file: No such file or directory in Unknown on line 0
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/mysqli.so' - libmysqlclient.so.15: cannot open shared object file: No such file or directory in Unknown on line 0
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/pdo_mysql.so' - libmysqlclient.so.15: cannot open shared object file: No such file or directory in Unknown on line 0
PHP version >= 5.3.0: FAIL
PHP version < 7.0.0: OK
mcrypt module installed: FAIL
simplexml module installed: OK
zlib module installed: OK
json module installed: FAIL
mhash module installed: FAIL
xmlwriter module installed: FAIL
mbstring module installed: FAIL
pdo module installed: OK
pdo_mysql installed: FAIL
gettext installed: OK
shell_exec function enabled: OK
curl function enabled: OK
Magic Quotes disabled: OK
You can also view this file in a browser

P.S. your yellow dots signature graphic looks like an ancient computer paper tape that I recall from a jillian years back when I took a class on machine computing ... haven't thought about that in a long time.
Or am I just revealing TMI.

I started coding with paper tape/cards .. in a galaxy far far away lost in time

shades of IBM punched 'Hollerith' cards ... yikes.

FYI for any interested in my particular resolution re install setup which then failed to let me login.

AMember Tech Support responded with two responses, and after the second one, I was able to get in.
In my case, it therefor did require direct access to the MySQL AMember database on our new host server.
The Support responses:
First:

"Please provide ftp info and username/password that does not work for you.
We will reset password."​

Second:

"I have checked the database and table am_admin was empty at all.
Not sure how and why it was truncated.
Anyway I have added new record and now you can login as admin using
username - admin
password - " xxxxxxxxxx (the reset password would be listed there)​

So if your encounter with the setup login error is similar to mine, AMember Support may need to take the same db manipulation password reset action.
Just FYI, Hope this may help...

What happens when all these checks pass, and still the cookie/session isn't being set ?

If it helps, along-side this issue, if you try to use the form to reset the password ( /admin-auth/send-pass ), it triggers the following error :

• CSRF protection error - form must be submitted within 60 minutes after displaying, please repeat

After more troubleshooting, there is some funny business with the sessions that I am noticing. In my old installation on a different subdomain, the session looks like, and this works :

Code:

PHPSESSID=68524731530adc2adddd15361f9be1f5; path=/; domain=.microvb.com; HttpOnly

However on the new box, I have renamed PHPSESSID to something more random (best practices for security), and the result (aside from the changed session name), is much longer :

Code:

ABBCGHHII=kf77d5fc4s60jt70j9ovsppg3c8e6fo99tuq4cedm9vvsfo77a51; expires=Sat, 12-Mar-2016 03:41:18 GMT; Max-Age=3600; path=/; domain=my.microvb.com; secure; HttpOnly

I also found that 'PHPSESSID' was hard-coded in /library/Am/Lite.php as a constant inside the class. Even after changing this to the actual session id 'ABBCCGHHII', I am still stuck in a login loop with no errors out. I do recall this being a session issue in the past, but the resolution is not documented anywhere.

In the amember database, it shows that the admin Login was successful, but still can't get past the login screen as it redirects back to it, no error, and still not logged in.

Why bother? Anyone with a partial brain will figure out that the renamed cookie is the session id, there is no great security reason to do it. If you are after securing information the absolute first thing to do is SSL, which I notice your site uses once that is in place the data is all encrypted going up/down so the names become irrelevant anyway.

jenolan : fair enough. it's more to keep the skiddie's out than any real hack attempts. amember should really be regenerating the session name instead of hard-coding PHPSESSID as a constant. Even for the skilled, a session name that is randomized is much more difficult to obtain the session data from via xss.

That being said, there is something very strange going on. I am going to test with the standard 'PHPSESSID' and see if that magically lets me login. Aside from the above noted file, I haven't really traced any deeper to see how far this rabbit hole goes.

UPDATE: Renaming the session back to PHPSESSID still fails to login. aMember log continues to show successful admin login. Browser displays no error, just the login form again.

If you set the cookie name to goomba or a random string it is still trivial t work out that the value of the cookie is the session id. If you use a fixed value, anything at all you are not really improving security one atomic level. All you are doing in the end is making it harder for maintenance.

Just like the forum scripts that let you rename example.com/forum/admin to a rubbish name to make it difficult for numnutz to try an admin crack. All the while ignoring the fact that the site is vulnerable from the standard user script(s). Don't get me wrong I am all for doing stuff that secures things, but just changing something to another value aint improving security.

I will get orf my soap box now

I agree completely. Having a different 'default' session id name set is by no means the end all fix for xss stuff if the script continues to use whatever was statically set instead of using a random name for each session, that being said, the different name for my session was not the cause of the continued failure to login. Just wish it would give me an error or something instead of just redirecting me back to the login page, and logging in amember db that everything is A-OK.

You wouldn't happen to have some ideas I could inspect to dig into this. It's been some time since I poked around in aMember.

I would make sure using the browser console that nothing silly is happening, the other check the cookie information, esp drop some debug code where the cookie is loaded and make sure that it aint getting confused.

Login/Cookie issues are always a real pest to resolve.

https://my.microvb.com/am/

I will open a ticket as well, but since my time lapsed for updates, the last person who replied to me 'encouraged' me to renew, which is something I am not about to do while things remain broken (in all fairness). I recall a similar issue in the past, but I do not recall what was done to resolve it. It would be really nice to have the fix for this documented somewhere.

Great job. This worked and allowed logins to function. It's going to take me a little bit to get used to amember4 again given it has been some time. Just poking around the documentation and source examples to refresh.

Not sure what I will release first, but possibly some new themes since there appears to be a shortage in this area (may rediscover why), and possible another protected file content plugin (rework from my opensource project on github Protected-Signed-URLs-Self-Hosted )