[RESOLVED] SSL connection error ..Locked out of Admin

[DanMc]

Trying to secure the Admin area I enabled SSL in ACP..and of course I managed to lock myself out.. I looked in Confing file but do not see the define for ssl.. I went to my server and disabled SSL temporarily and still get the SSL connection error.. where oh where can I disable it?

THANKS !

[rct2·com]

Nasty.

The SSL switch is stored in 2 places in the database. You are going to have to use something like phpMyAdmin to edit the database by hand to reset it. Do you have something like phpMyadmin that you can use?

[AndyF]

Although you *can* disable it in the settings via editing the db manually, it won't take effect as the settings are cached. You'd need to use the upgradefinish tool to rebuild the caches externally. :)

If you're not sure please submit a ticket in the Client Area.

[rct2·com]

Out of interest Andy, can you manually flush the cache by deleting the row in the cache_store table? Would that force the board to rebuild the cache with the new setting, also previously manually edited?

[DanMc]

Thanks Guys I put in a support ticket for it.

I do have PhpAdmin ..rct2 I think one of the setting sis in

core_sys_conf_settings but couldn't locate the other.. besides figure It's best not play anymore :smile: .. For future reference which tables were you talking about ?

[AndyF]

I don't *think* that would work if you emptied that you'd have more problems. The upgradefinish tool will rebuild them (amongst other things) if you have to "manually" change a setting because you have no ACP access to do it normally. Its quite easy to use.

[rct2·com]

core_sys_conf_settings is where the setting is stored yes. But to improve board performance, those settings are cached into the cache_store table where they can be more efficiently loaded and unpacked.

The cached https login setting is buried in the cs_value field in the cache_store table in the row where field cs_key="settings"

On my test board (https login is off) the relevant part of the the cs_value field is

s:17:"logins_over_https";s:1:"0";

For you, I'd imagine that the "0" is "1". But phpMyadmin isn't confident that you can edit that cs_value field by hand because the contents are very large. :smile:

It's possible **untested** that if you set the variable in the core_sys_conf_settings to NULL or 0, then delete the row in cache_store where cs_key="settings" (or temporarily changed "settings" to something else to test, then change it back if the test fails) , then this will force the code to recache that row, and take your new value from core_sys_conf_settings.

***EDIT***: This definitely does not work, causes a fatal error.

[Rhett]

After you edit the setting directly in the data

Although you *can* disable it in the settings via editing the db manually, it won't take effect as the settings are cached. You'd need to use the upgradefinish tool to rebuild the caches externally. :smile:

If you're not sure please submit a ticket in the Client Area.

This is the only answer/solution :)

[rct2·com]

I just set https login on my test board to 'Yes' , logged out of AdminCP and confirmed that I could no longer access AdminCP. (Idon't have SSL set up on my test board).

Then in PHPMyAdmin I ran this query. (It changes the cached login over https value to 'No'.)

update `cache_store` set cs_value = replace(cs_value, "s:17:""logins_over_https"";s:1:""1""", "s:17:""logins_over_https"";s:1:""0""") WHERE cs_key="settings";

I confirmed that I could login again to AdminCP using http (and not https). Then very quickly went to AdminCP and switched https login back to 'No' :smile:

[DanMc]

core_sys_conf_settings is where the setting is stored yes. But to improve board performance, those settings are cached into the cache_store table where they can be more efficiently loaded and unpacked.

The cached https login setting is buried in the cs_value field in the cache_store table in the row where field cs_key="settings"

On my test board (https login is off) the relevant part of the the cs_value field is

For you, I'd imagine that the "0" is "1". But phpMyadmin isn't confident that you can edit that cs_value field by hand because the contents are very large. :smile:

It's possible **untested** that if you set the variable in the core_sys_conf_settings to NULL or 0, then delete the row in cache_store where cs_key="settings" (or temporarily changed "settings" to something else to test, then change it back if the test fails) , then this will force the code to recache that row, and take your new value from core_sys_conf_settings.

***EDIT***: This definitely does not work, causes a fatal error.

Wow I would have "guessed " right cache_store table....and yes on or off ..1/0 ..

rct2.. thanks for testing as well.. and for the PhpmyAdmin Quesry for future reference (not that I plan on making the same mistake twice..just that I have NEVER "planned" on making the second mistake twice ever before :lol: )

And thanks to IPB support Robert for getting me back in !

[Rhett]

We're glad that this has been resolved for you. If you have any further questions or issues, please feel free to start a new support topic.

Thank you!