Answer the question
In order to leave comments, you need to log in
How to solve the problem with duplicate sessions in Bitrix24?
Hello!
Friends, comrades, gentlemen and beautiful ladies!
Please help me restore my mental state, otherwise another crazy person will soon be running around the streets, shouting something indistinct, a bit reminiscent of the phrase "was NOT a subdomain of a site that does NOT work for Bitrix".
So, for a week now, I’ve probably been chatting with Bitrix technical support and I can’t get something out of my head.
After the next update, all users of the portal at the top of the browser window got a red line with the message "There is no connection to the server":
It was not possible to contact technical support via chat at that moment, because chats did not work due to this error. I applied through the Bitrix website, but they did not help me. Helped another company that is engaged in the integration of Bitrix, from which we bought training services.
However, the problem was not completely solved. Managers now start every morning by clearing cookies and cache, otherwise this error appears. In the process of communicating with technical support, I had the thought of suicide. Not immediately, of course, at first there was anger, denial. For a long time I could not understand at all what the specialist at the other end of the chat wanted from me.
So, the portal was opened at the address (intentionally changed) spb.bitrix.domain.net .
The specialist throws me a link and says that "that the portal should NOT be a subdomain of the site. ". I start frantically
climbing through the Sites section on the portal and looking at the settings there, at the same time trying to find out what is meant.
for 1 box, but it didn’t end well and now we decided that fuck it, we’ll try it ourselves somehow.Since
only one of the 4 working branches is working now, I ask:
What if I delete all the sites, but in one the rest I will delete the spb subdomain, i.e. it will literally be bitrix.domain.net, then it will work like that?The answer was - YES !
Well, in the sites section I tried to delete sites, which did not work due to some error, in the end I deactivated them, and removed spb in one.
And guess what, the problem didn't go away. I chat again, and the same specialist again repeats to me that " bitrix.domain.net should not be a subdomain. We have already discussed this with you above. " My valve knocks out and I hit the table with my fists... WTF in my head?!?!?!
I start asking him, but in response, the same "The bitrix.domain.net portal should not be a subdomain of the site."
Already in desperation I ask "What do you even mean by a site? What site?". In response, I hear "domain.net".
In my head at that moment - "Oh, yes! Of course! Something I'm stupid!".
Here I suddenly begin to suspect something is wrong and ask "Do you mean the site of the domain.net company by the site?".
The answer is "Yes."
@#$%%^$#&^!!!!! - Runs through my head.
Me: - And what does the site have to do with it? It's not related to Bitra, it's hosted by who knows where. I will now redirect DNS to bitra and then you will tell me that "domain.net cannot be a subdomain of net". So we will go down to the DNS root.
As a result, I got such an answer from a specialist that "If there is a domain.net site and it is not located on the Bitrix server, then the site portal itself cannot be assigned the name of any of the domain.net subdomains."
And we have bitrix.domain.net aimed at a server with a bitr, and domain.net is aimed at a server with a website, and these two servers are two different servers with different IPs. This results in duplicate sessions.
For me, it's totally weird.
I would like to hear an alternative opinion of specialists who work with Bitrix. I believe that there are knowledgeable people on the Internet.
Thank you for your attention and sorry for the bunch of letters.
Answer the question
In order to leave comments, you need to log in
1C-Bitrix in the latest updates (20+) has carried out extensive work on product security, as well as changes in internal subsystems. One of these steps was to change the mechanism for storing session files and cookies, which could not but affect the "good old 'everything worked before'".
The error you are giving is due to the `PHPSESSID` cookie, which stores the session ID of the logged in user. For any site, a cookie is not just a key-value pair, but a slightly more complex mechanism that includes the expiration time and the domain that issued it. In general practice, this key should correspond to only one value - the one that the site issued.
What happens after the latest updates?
For convenience, consider a company: company.org. A cookie can be issued in several ways: to a specific domain and to a domain group, and the domain group is all subsites of the current site. If B24 finds b24.company.org on the subdomain, then a cookie called `PHPSESSID` can be set for both b24.company.org and company.org, so there will be no problem for company.org, while for B24 this will create huge problems. Accordingly, the lower the domain level, the more sites can affect it. For example, for: spb.b24.company.org, as many as 3 sites can do this (spb.b24.company.org, b24.company.org, company.org).
What to do?
There are several options. For example, the simplest of them:
1) Simulate an error
2) Open the developer console in the browser, a tab with cookies
3) See who issued the extra cookie (there may be 2 entries: ".b24.company.org" and ".company.org"). Extra cookies are cookies that do not have the portal address directly in their domain. In the given example, this is ".company.org"
4) Reconfigure the site "company.org" so that it does not issue cookies for the domain group or change the name of the cookie variable.
The method is much more complicated: you can change the `session.name` parameter on the web server where Bitrix24 is located from the `PHPSESSID` value to something more unique and modify some of the Bitrix24 subsystems so that they use the new name. However, this item has a very large asterisk, so I recommend choosing a simple option.
There are two solutions
1. Transfer the portal to another domain. It is possible to a subdomain of another domain, but then the record type in the DNS must be A (not CNAME).
2. Disable the checkbox in the settings of the main module - distribute cookies to all domains (this is in the admin panel). This option helps if the front is given to nginx and it is properly configured.
Didn't find what you were looking for?
Ask your questionAsk a Question
731 491 924 answers to any question