General Support2 amoun Nov 04, 2017 17:41
b2evolution CMS Support Forums- b2evolution Support
- General Support
- Unable to Login after Upgrade to 6.9.3-stable
1 josephdp Nov 03, 2017 08:09
3 josephdp Nov 04, 2017 19:26
I see the bad the request, and even the line of code in the inc/_core/_param.funcs.php file. However, they aren't bad requests, that is, the parameters being passed seem correct, but aren't being processed..
Yes, I can go back to a previous version, which is how I did the reinstall.
But I would prefer to see this bug fixed.
Thank you for taking a look at this.
4 amoun Nov 04, 2017 22:46
Trying to get my head around your problem
"I am unable to login after upgrading to 6.9.3 stable. The front-end is working fine. I did a clean upgrade, that is, I deleted all previous b2evolution files, except for the stub files for the various blogs. I copied over the files from the unpacked 6.9.3 archive. I assured that owner:group were correct, and opened up the permissions to rwx for owner, group and all. I brought back conf/_basic_config.php, and ran the install as an upgrade. I brought back the skins that we use, and media files. The front-end looked great. I tried to login, and just came back to htsrv/login.php. My first thought was cookie or cookies domain. I cleared browser cache, history and cookies…to no avail. "
All that seems fine and works fine on my upgrade
but have no idea on what you have done here
" I am using the programmatic setting for $baseurl as hardcoding gives a too many redirects error. The programmatic way worked in the past, and still seems to be working."
but then as the first part works for me ??
The only issue I've had on new installs lately were bad permission in the install folder which you seemed to have passed.
Can you install to a different server? to see if it works
5 josephdp Nov 05, 2017 01:27
@amoun Thank you again for working with me on this.
In conf/_basic_config.php one can hardcode the $baseurl or one can allow the php to programmatically find the URI of the site. As we are actually planning on running several domains through b2evolution, and have done so since we first started using b2evo in 2005, we use the programmatic method, as follows:
/**
* $baseurl is where your blogs reside by default. CHECK THIS CAREFULLY or nothing will work.
* It should be set to the URL where you can find the blog templates and/or the blog stub files,
* that means index.php, blog1.php, blog2.php, etc. as well as admin.php.
* Note: Blogs can be in subdirectories of the baseurl. However, no blog should be outside
* of there, or some tricky things may fail (including intempestive logouts)
*
* IMPORTANT: If you want to test b2evolution on your local machine, do NOT use that machine's
* name in the $baseurl!
* For example, if your machine is called HOMER, do not use http://homer/b2evolution/blogs/ !
* Use http://localhost/b2evolution/blogs/ instead. And log in on localhost too, not homer!
* If you don't, login cookies will not hold.
*
* @global string $baseurl
*/
//$baseurl = 'http://press.teleinteractive.net/';
// Use the following if you want to use the current domain:
if( isset($_SERVER['HTTP_HOST']) )
{ // This only works if HOST is provided by webserver (i-e DOES NOT WORK IN PHP CLI MODE)
$baseurl = ( (isset($_SERVER['HTTPS']) && ( $_SERVER['HTTPS'] != 'off' ) ) ?'https://':'http://')
.$_SERVER['HTTP_HOST'].'/';
}
The $baseurl is important in setting the cookies domain, and login depends on cookies, so the cookies domain must be correct for the cookies to allow the login to work. At least, that is my, possibly faulty, understanding.
I've only played around with PHP programming. Most of my experience is in SQL (ANSI and PL/SQL mostly) and The R Programming language, and I am rusty in both. I am not seeing any MySQL problems. Most of my SysAd experience (from 24 years ago) is in Unix (prefer BSD variants) RHEL Linux, and now the Mac OS X flavor of BSD Unix.
I do have an old iMac at home running Server.app and could try to install b2evo there, using the instructions for installing on a local machine. Good idea, thank you. There may still be some odd permissions issue, as I seem to have had to open up the permissions more than I like to get actual blog pages to show up; in this version vs the previous version that I used. I should also mentioned that I tried to upgrade to a 6.8.6 v2evo version, and that failed at a time when I couldn't look into it further, so I just went back to what I was using previously, 6.6.7.
Hey, Manuel @mgsolipa or François @fplanque – any ideas?
Thank you all. We will get this figured out.
__---
Best Regards,
Joseph
6 amoun Nov 06, 2017 02:32
OK sorry to be a bit slow on this
Do you only have one domain currently, and can you log in ok with
$baseurl = 'http://press.teleinteractive.net/'
7 josephdp Nov 06, 2017 19:50
If I allow _basic_config.php to hard code $baseurl then web browsers give too many redirect errors. The programmatic methods is the one that works for our platform.
No, I can not login under wither domain that is currently active, nor from the FQDN of the server.
The main blogs are at https://press.teleinteractive.net/
We have another set up now for https://saeiot.com/
The FQDN is fortuna.teleinteractive.net
I had also tried setting Server.app | Web to NOT ALLOW and to ALLOW .htaccess override. Either setting seems to work the same.
I didn't think to try this before, but I can login through localhost/admin.php
Of course, that I means that I need to VNC into the server; but it is at least a workaround for now.
Thank you again for all of your help @amoun
8 amoun Nov 06, 2017 20:15
Your are definitely in an area I'm unfamiliar with so i don't think I can comment any more. All the best
9 josephdp Nov 06, 2017 21:47
10 mgsolipa Nov 06, 2017 23:20
@josephdp I tried to reproduce the issue in my Mac with no luck.
The first thing I can see from your site is it's mixing https and http contents. Idea: can you test temporarily removing https?
11 josephdp Nov 07, 2017 05:54
Manuel,
Turing off the redirects to the SSL URL allows me to login from a remote machine, either to http or https. When I log into https, I and logged in, but an error appears saying that password hashing failed, that I was logged in insecurely, and that I should contact an administrator.
Since our sites are all b2evo, this means that b2evo is serving up a mix of secure and unsecured URLs. Is the programmatic way of providing $basurl in _basic_config.php broken? I think so, in that I pulled the code out, added a line to echo $baseurl, and when I access https://press.teleinteractive.net/testBaseURI.php the $baseurl is given as http://press.teleinteractive.net/
I will see if I can figure out how to rewrite the code, so that only https is provided, and see if that works.
Thank you for your help @mgsolipa
12 josephdp Nov 07, 2017 21:19
Forcing the $baseurl to be https:// helped but created a new problem, @mgsolipa – The login page no longer has a mix of secure and insecure content, and I can login remotely. But, I am returned to the front page; with the full menu bar. When I try to go to the backoffice, I get too many redirects error.
Whether or not I am forcing the $baseurl to https, I also see that the skins (CSS) are not being rendered on the blogs.The main collection, which gathers all the blogs under press.teleinteractive.net, shows properly, and its base href, as shown in view source, is /skins/<sknName> For the others, the base href is /<blogName>/skins/<skinName>. Perhaps I should make this as a new issue.
13 josephdp Nov 08, 2017 07:05
I remember now that when we first changed from RHEL to Mac OS X for our server, and using LetsEncrypt certificates, there was some playing around to do in the URL settings for each collection. I need to use an absolute path for all assets in collections | settings | URL I have now done this, and that is working again.
I can only login from localhost though, and as @mgsolipa says, it is likely due to a mix of secure and insecure content being served. So, the original problem remains, and I still need to keep looking for settings in /conf/ files or in the backoffice.
Thank you to all who help or empathize in this community.
14 josephdp Nov 08, 2017 21:59
I've added the following to the top of conf/_advanced.php
/**
* To reslove an issue with Mac OS X Server.app Webserver
* that makes websites appear to be behind some form of double proxy,
* We need to hardcode the location of htsrv and rsc subdirectories and
* while this isn't a good solution, it does work - however,
* if the server FQDN changes, then this breaks
* Using $baseurl won't work, that will give too many redirect errors.
* With PHP v5.3.0 and greater, use the following to programmatically hard code the location of
* the htsrv and rsc directories using $hostname
* We will declare the variable here, and use it below
*/
$hostname = gethostname();
And then changed the following for htsrv and rsc subdirectory locators.
/**
* Location of the HTml SeRVices folder.
*
* Note: This folder NEEDS to by accessible through HTTP.
*
* @global string $htsrv_subdir
* @global string $htsrv_path
* @global string $htsrv_url This applies only to the backoffice. For the frontoffice, the URL will be dynamically generated by function get_htsrv_url( false )
*/
$htsrv_subdir = 'htsrv/'; // Subdirectory relative to base
$htsrv_path = $basepath.$htsrv_subdir; // You should not need to change this
$htsrv_url = 'https://'.$hostname.'/'.$htsrv_subdir; // Changed to use FQDN rather than $baseurl for Mac OS X
//$htsrv_url = ( (isset($_SERVER['HTTPS']) && ( $_SERVER['HTTPS'] != 'off' ) ) ?'https://':'http://').$_SERVER['HTTP_HOST'].'/htsrv/'; //may be needed for multiple domains
//$htsrv_url = $baseurl.$htsrv_subdir; // You should not need to change this
/**
* Sensitive URL to the htsrv folder.
*
* Set this separately (based on {@link $htsrv_url}), if you want to use
* SSL for login, registration and profile updates (where passwords are
* involved), but not for the whole htsrv scripts.
*
* @global string $htsrv_url_sensitive This applies only to the backoffice. For the frontoffice, the URL will be dynamically generated by function get_htsrv_url( true )
*/
$htsrv_url_sensitive = $htsrv_url;
//$htsrv_url_sensitive = 'https://'.$hostname.'/'.$htsrv_subdir;
//$htsrv_url_sensitive = 'http://localhost/'.$htsrv_subdir;
/**
* Location of the RSC folder.
*
* Note: This folder NEEDS to by accessible through HTTP. It MAY be replicated on a CDN.
*
* @global string $rsc_subdir
* @global string $rsc_path
* @global string $rsc_url This applies only to the backoffice. For the frontoffice, the URL will be dynamically generated by function Blog->get_local_rsc_url()
* @global string $rsc_uri
*/
$rsc_subdir = 'rsc/'; // Subdirectory relative to base
$rsc_path = $basepath.$rsc_subdir; // You should not need to change this
//$rsc_url = $assets_baseurl.$rsc_subdir; // You should not need to change this - original code before use of $hostname for Mac OS X
$rsc_url = 'https://'.$hostname.'/'.$rsc_subdir; // Changed to use FQDN rather than $baseurl for Mac OS X
//$rsc_url = $baseurl.$rsc_subdir; // You should not need to change this
$rsc_uri = $basesubpath.$rsc_subdir;
And this seems to work, in my limited testing so far.
Again, thank you @amoun and @mgsolipa for all your help. BTW, Manuel, this is based on the hard coding that you did in our conf/_advanced.php file when we first moved from RHEL to Mac OS X server. That Mac Mini Server host had been acquired and our machine was moved to a new facility, prompting a change to FQDN.
Similar for trying to register
https://press.teleinteractive.net/htsrv/register.php?source=menu%2520link&redirect_to=%252F%253Fdisp%253Dposts&return_to=%252F%253Fdisp%253Dposts
"Bad Request!
The parameters of your request are invalid.
If you have obtained this error by clicking on a link INSIDE of this site, please report the bad link to the administrator."
Can you go back to the previous version?