Recent Topics

6.10.2 : Can't create new collection

Started by on Sep 09, 2018 – Contents updated: Sep 24, 2018

Sep 09, 2018 17:21    

Hello :)

I am trying to create a new collection to replace the demo frontpage collection I have installed on the fresh installation of 6.10.2 stable, I select "new collection", then choose the skin "bootstrap main", then configure to aggregate content, not to include demo content, give "test" as a title and beadcrumb, give access for everyone, leave admin as the owner, click "enregistrer les modifications" (I use french interface), and go to a login page afterwards. If I enter my login/password (for admin) - nothing happens, just keep getting to the same page (there is no password related error, no other error shown).

If I try to open some other page on the site afterwards, it is asking me to login for one more time, but this time the login works and I can get to the site.

Looks like the session is getting lost, but happens only when I try to add a new collection the rest of admin backoffice is working fine..
Here is some debug info when I get to the login page:

`
Debug info
HTTP Response code: 200
$content_type_header: Content-type: text/html; charset=utf-8
$disp: -- detail:
$robots_index:
$robots_follow:
8 SQL queries executed in 0.019 seconds scroll down to details
Timers
.....
Opcode cache: OPCache
User cache: APCu

Memory usage: 13 Mo
Memory peak usage: 13 Mo
Len of serialized $cache_imgsize: 2
Len of serialized $cache_File: 2

Debug messages

note | _init_login | locale | request | timer

note:
redirect_to: /admin.php
return_to: /admin.php
_init_login:
Login: login: ''
Login: pass: empty
Login: NOT logged in... (did not try)
Login error:
Param inskin:
Using standard login

locale:
Set DB connection charset: utf8
Login: default_locale from conf: en-US
Login: default_locale from DB: en-US
Login: default_locale from HTTP_ACCEPT: fr-FR
evo_charset: utf-8
io_charset: utf-8
We need to load a new translation file to translate: "Log in to your account"
T_: Loading file: ****/locales/fr_FR/_global.php

request:
vars: vars: Getting ReqURI from REQUEST_URI
vars: $ReqHost: http://*****
vars: $ReqURI: /admin.php
vars: $ReqPath: /admin.php
Hit: IP: 90.86.33.65
Hit: UserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.106 Safari/537.36
Hit: Referer: 'http://***/admin.php?ctrl=collections&action=new-name&kind=main&skin_ID=2'; type=self
Hit: Remote Host(NO nslookup):
Session: cookie_domain=***.***.org
Session: cookie_path=/
Session: No session cookie received.
Session: ID (generated): 23
Session: Cookie sent.
Session: Session data[crumb_latest_loginform] updated. Expire in: -.
Session: Session data[core.pepper] updated. Expire in: 86400s.
Session: Session data saved!
Session: Session data[crumb_latest_loginsalt] updated. Expire in: -.
Hash key: 71
Hit: Hit NOT logged, (Admin page logging is disabled)
Session: Session data saved!

timer:
total resumed at 0.000

_init_base resumed at 0.000
    first_flush resumed at 0.000
        _MAIN.inc resumed at 0.000
        _init_base paused at 0.014 (+0.0136)
        _init_db resumed at 0.000
        _init_db paused at 0.010 (+0.0099)
        init modules resumed at 0.000
        init modules paused at 0.061 (+0.0609)
        plugin_init resumed at 0.000
        plugin_init paused at 0.003 (+0.0025)
        _init_hit resumed at 0.000
            Hit::get_remote_host resumed at 0.000
            Hit::get_remote_host paused at 0.000 (+0.0001)
        _init_hit paused at 0.011 (+0.0107)
        _init_session resumed at 0.000
            _init_session__new resumed at 0.000
            _init_session__new paused at 0.008 (+0.0081)
            _init_session__new stopped at 0.008
            _init_session__plugin resumed at 0.000
            _init_session__plugin paused at 0.000 (+0.0001)
            _init_session__plugin stopped at 0.000
            _init_session__user_settings resumed at 0.000
            _init_session__user_settings paused at 0.001 (+0.0010)
            _init_session__user_settings stopped at 0.001
        _init_session paused at 0.012 (+0.0119)
        _init_login resumed at 0.000
            shutdown resumed at 0.000

`

Sep 09, 2018 17:29

have advanced a bit in the investigation.
The cookie "b2evo_session" gets deleted on the page
/admin.php?ctrl=collections&action=new-name&kind=main&skin_ID=2

because of the request (from this page)
/htsrv/rest.php?api_version=1&api_request=tools/available_urlname&urlname=home

which sends this header
Set-Cookie: session_b2evo=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0; path=/; domain=*.*.org; httponly

with 403 response code and response body
{"code":"wrong_login_pass","message":"Identifiant\/mot de passe incorrects.","data":{"status":"403"}}

Additional info, could help:

The rest api /api/v6/collections on this setup is not functional, because I use nginx and did not add the corresponding rewrite rule for the moment.

xml-rpc is not working neither because the site is http basic auth protected.

Sep 09, 2018 22:27

well, there are some really strange decisions behind the code.

Added a rule to rewrite apache rule
RewriteRule ^api/v(\d+)/(.+)$ htsrv/rest.php?api_version=$1&api_request=$2 [QSA,L]
for nginx

but it did not help. Started to look in to the code and discovered that in _restapi.class.php there is a function user_authentication()
which checks if there are http basic auth headers set, and tries to log in the user defined in those headers using b2evo authentification.

So, to make it work I had to add another user (admin with the same password as for b2evo) in to nginx basic auth password config, and it started to work.

Can't understand why you need to do that, what was the reason to map http basic auth to b2evo auth in such strange way?

Well, now I am able to create new collection, so we can close this ticket. If anyone want to protect their dev site with http basic auth, they have to use the same admin user and password as for b2evo.

Sep 13, 2018 08:49

what we can do is to check if there already is a user session active and use credentials from this active session for REST authentification. And use HTTP Basic Auth only if no session is present (that's what I did actually).

Sep 13, 2018 15:12

Hum, I think that HTTP Basic auth also creates a session... so if an active session makes it impossible to use HTTP Basic auth, then it will be difficult for users to switch to another user once they have used Basic auth the first time (or in the case of a security / SSO front-end, it may be a requirement to check the authentication on every request)

Sep 14, 2018 10:47

session is initialized and maintained by php, HTTP_BASIC_AUTH is implemented by a webserver. So i is checked before the request arrives to php module.

If a user has an active php session and is authenticated, I don't see any reason to use http_basic_auth for this user (except to protect the development site from unwanted visitors).

Moreover, I don't see any reason to protect the API by http basic auth, because to use this api you'll have to provide the login and the password in the code and pass it as a clear text. So it could be retrieved by anyone interested.

So, if you want to protect the public api from unauthorized use, you'll have to use one of the modern approaches.. (public/private keys, oauth if client is able to keep cookies, optional ip whitelisting).

Sep 15, 2018 00:52

HTTP_BASIC_AUTH is implemented by a webserver. So i is checked before the request arrives to php module.

Not necessarily. There is no requirement that the HTTP_BASIC_AUTH headers by intercepted by the webserver.

If a user has an active php session and is authenticated, I don't see any reason to use http_basic_auth for this user (except to protect the development site from unwanted visitors).

The reason for HTTP_BASIC_AUTH is single sign-on in enterprise intranet installations. The BASIC AUTH is used only between the authentication front-end and the application server.

Moreover, I don't see any reason to protect the API by http basic auth, because to use this api you'll have to provide the login and the password in the code and pass it as a clear text. So it could be retrieved by anyone interested.

If you use the API though https, nothing is clear text.

So, if you want to protect the public api from unauthorized use, you'll have to use one of the modern approaches.. (public/private keys, oauth if client is able to keep cookies, optional ip whitelisting).

These are all good things to add but they do not invalidate the potential need for HTTP_BASIC_AUTH.

Sep 17, 2018 09:52

thanks for the explications, appreciate it.

Not necessarily. There is no requirement that the HTTP_BASIC_AUTH headers by intercepted by the webserver.


agree! But if you implement it by your own, you have to provide not only authentification, but also logout to force the browsers to clear the http_basic_auth user:password cache (which could be a broblem) and also show login prompt in case of failed authentification.
Looks like it is onlypartially implemented in b2evo and that's why I got confused with basic auth location protection I have used to limit access to my dev server.

The reason for HTTP_BASIC_AUTH is single sign-on in enterprise intranet installations. The BASIC AUTH is used only between the authentication front-end and the application server.


If you use the API though https, nothing is clear text.


but you have it in clear text on the front end! A quick look through the scripts of the page will reveal the login/password and compromise the site because the same password could be used to login to the control panel. On my opinion it is better to separate access to api from access to the website. Or make it work only other way round, if user has access to the website, he has access to api without authentication.

Sure, it is much more difficult to intercept passwords in case of https, but it means that you have to disable HTTP_BASIC_AUTH in b2evo if you detect that http is used :)

Anyway, now I understand why it was done like that, and don't see any immediate need to change anything. I'll take my time to get used to the ecosystem and propose my way to work with api if I see that I can improve things.

Anyways, we can probably make HTTP_BASIC_AUTH optional. Can you please confirm you have already turned if off here:


did not notice that one, thanks!
Gave a quick glance in the code - looks like this parameter is not used in the _restapi.class :(

Sep 24, 2018 16:30

for the record, here is my way to fix this bug
(lines 167-175 of _restapi.class.php)

	private function user_authentication()
	{
		global $Session;

		if(!$Session->get_User() && isset( $_SERVER, $_SERVER['PHP_AUTH_USER'] ) )
		{	// Do basic HTTP authentication:
			$this->user_log_in( $_SERVER['PHP_AUTH_USER'], $_SERVER['PHP_AUTH_PW'] );
		}
	}


Form is loading...

powered by b2evolution free blog software – This forum is powered by b2evolution CMS, a complete engine for your website.