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.

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.

We did that in order to have authentication for the REST API: https://b2evolution.net/man/rest-api-basic-http-authentication

We did not really realize it would interfere in a use case such as yours.

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).

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)

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).

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.

Anyways, we can probably make HTTP_BASIC_AUTH optional. Can you please confirm you have already turned if off here:
https://b2evolution.net/man/registration-security-settings

thanks for the explications, appreciate it.

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

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.

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:

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'] );
		}
	}

I had this exact same issue. New install with demo content "6.10.3-stable released on 02/10/18 ".

I want to confirm that the solution provided by "dm" worked perfectly. I was able to edit a collection, but if i changed the owner the site asked me to login, but i was unable. I was unable to create new collections.

as an aside: collections/settings/urls
SSL: Always use http

Having the default be "Alwasy use http" caused my days of grief as my site is https. I think the better default for collections should be "Allow both http and https as valid URLs ". My apache configuration automatically forces https. Your default caused endless redirection loops.

@dm Thank you for the detected bug and for the suggested solution, we fixed this in commit https://github.com/b2evolution/b2evolution/commit/d50c68d1f9a5d145680927a66390c54ccab5815d:

	private function user_authentication()
	{
		global $current_User;

		if( isset( $_SERVER, $_SERVER['PHP_AUTH_USER'] ) &&
		    ( ! is_logged_in() || $current_User->get( 'login' ) != $_SERVER['PHP_AUTH_USER'] ) )
		{	// Do basic HTTP authentication when user login is provided AND
			// user is not logged in yet OR the provided login is defferent than login of the current User:
			$this->user_log_in( $_SERVER['PHP_AUTH_USER'], $_SERVER['PHP_AUTH_PW'] );
		}
	}