Hi,
I use SID to share basket for multi-websites but since last update on M 2.3.3 AND on M 2.2.10 the configuration field relative to this in the backend : "Use SID on Storefront" is missing and all my custom work stop working.
I can't find any information about this modification in forum, neither relese note.
Please can you tell me why this option suddently disapear ? is it a bug ?
Without this, my custom dev can't share order info between different websites domain name.
Thanks a lot for your help.
Hi @angelflo. Thank you for your report.
To help us process this issue please make sure that you provided the following information:
Please make sure that the issue is reproducible on the vanilla Magento instance following Steps to reproduce. To deploy vanilla Magento instance on our environment, please, add a comment to the issue:
@magento give me 2.3-develop instance - upcoming 2.3.x release
For more details, please, review the Magento Contributor Assistant documentation.
@angelflo do you confirm that you were able to reproduce the issue on vanilla Magento instance following steps to reproduce?
Hi @angelflo,
AFAIK it was removed due to security reasons.
Could you describe use case when it's needed?
It's needed when we use multiple website feature (rootdomain.com, domain1.com, domain2.com)
and when I need to centralise all the payment from a secure domain via rootdomain.com).
So after saving the order in the corresponding website (for exemple domain1.com), i need to redirect to the SSL secured domain rootdomain.com who's approuved by our payment provider.
It seeems that without this SID param, I now can't share the order info with the rootdomain !
This parameter was removed due to security reasons, I don’t believe it will
be added back, as security is more important.
What you describe - looks really custom flow. I suggest you to have SSL
certificates on all domains, for instance using Letsencrypt.
On Wed, 20 Nov 2019 at 15:11, angelflo notifications@github.com wrote:
It's needed when we use multiple website feature (rootdomain.com,
domain1.com, domain2.com)
and when I need to centralise all the payment from a secure domain via
rootdomain.com).
So after saving the order in the corresponding website (for exemple
domain1.com), i need to redirect to the SSL secured domain rootdomain.com
who's approuved by our payment provider.
It seeems that without this SID param, I now can't share the order info
with the rootdomain !—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/magento/magento2/issues/25663?email_source=notifications&email_token=AAOJOUKM7GKHOVLUGGNVPYLQUUZP3A5CNFSM4JPOZ4QKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEER5L3Q#issuecomment-555996654,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAOJOULU2FHTIZQKVP5GTV3QUUZP3ANCNFSM4JPOZ4QA
.
Hi again,
Thanks a lot but we choose Magento especially because it's modular and allow this specific feature and we invest a lot in extensions + custom dev on this solution, now it's to late for us to switch on prestashop !
I really don't understand why Magento team remove it ... I can totally understand that it can create security breach but in specific situation it's really mandatory, this is why the solution where people can choose to enable or disable it (like this is the case previously) seems to be the good solution.
I'm ok with you to disable it by default , but leave the choice to enable it if it's really mandatory for some specific case.
Also, thanks a lot for your suggestion with letsencrypt, but it doesn't fit what we need for our business...
Please, leave the choice to people to choose by himself between high security or medium ... this is exactly the same than if I block all ports on firewall ... i improve security but I can't use web server, if I allow traffic I add some risk but I can do business.
In this case you could customize magento functionality to bring this
feature back for you
On Wed, 20 Nov 2019 at 18:15, angelflo notifications@github.com wrote:
Hi again,
Thanks a lot but we choose Magento especially because it's modular and
allow this specific feature and we invest a lot in extensions + custom dev
on this solution, now it's to late for us to switch on prestashop !
I really don't understand why Magento team remove it ... I can totally
understand that it can create security breach but in specific situation
it's really mandatory, this is why the solution where people can choose to
enable or disable it (like this is the case previously) seems to be the
good solution.
I'm ok with you to disable it by default , but leave the choice to enable
it if it's really mandatory for some specific case.
Also, thanks a lot for your suggestion with letsencrypt, but it doesn't
fit what we need for our business...
Please, leave the choice to people to choose by himself between high
security or medium ... this is exactly the same than if I block all ports
on firewall ... i improve security but I can't use web server, if I allow
traffic I add some risk but I can do business.—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/magento/magento2/issues/25663?email_source=notifications&email_token=AAOJOUNGBMZBF4ZDIZNHUJTQUVPDXA5CNFSM4JPOZ4QKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEESRULA#issuecomment-556079660,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAOJOUNHP7VBOJY2OHBWQSTQUVPDXANCNFSM4JPOZ4QA
.
does your code is still active ? can I force re-enable it easly (with just
one param ?)
Le mer. 20 nov. 2019 Ă 17:17, Ihor Sviziev notifications@github.com a
écrit :
In this case you could customize magento functionality to bring this
feature back for youOn Wed, 20 Nov 2019 at 18:15, angelflo notifications@github.com wrote:
Hi again,
Thanks a lot but we choose Magento especially because it's modular and
allow this specific feature and we invest a lot in extensions + custom
dev
on this solution, now it's to late for us to switch on prestashop !
I really don't understand why Magento team remove it ... I can totally
understand that it can create security breach but in specific situation
it's really mandatory, this is why the solution where people can choose
to
enable or disable it (like this is the case previously) seems to be the
good solution.
I'm ok with you to disable it by default , but leave the choice to enable
it if it's really mandatory for some specific case.
Also, thanks a lot for your suggestion with letsencrypt, but it doesn't
fit what we need for our business...
Please, leave the choice to people to choose by himself between high
security or medium ... this is exactly the same than if I block all ports
on firewall ... i improve security but I can't use web server, if I allow
traffic I add some risk but I can do business.—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<
https://github.com/magento/magento2/issues/25663?email_source=notifications&email_token=AAOJOUNGBMZBF4ZDIZNHUJTQUVPDXA5CNFSM4JPOZ4QKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEESRULA#issuecomment-556079660
,
or unsubscribe
<
https://github.com/notifications/unsubscribe-auth/AAOJOUNHP7VBOJY2OHBWQSTQUVPDXANCNFSM4JPOZ4QA.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/magento/magento2/issues/25663?email_source=notifications&email_token=ACL7K4T4OTHPG446UIG2Y7TQUVPIVA5CNFSM4JPOZ4QKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEESRZFI#issuecomment-556080277,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACL7K4STS7N4ECQNI2NG7TTQUVPIVANCNFSM4JPOZ4QA
.
I didn’t investigated how to add it back. You could review changes from
2.3.2 till 2.3.2-p2 ( there only security changes included) and see what
exactly was changed and just bring it back for you
On Wed, 20 Nov 2019 at 18:19, angelflo notifications@github.com wrote:
does your code is still active ? can I force re-enable it easly (with just
one param ?)Le mer. 20 nov. 2019 Ă 17:17, Ihor Sviziev notifications@github.com a
écrit :In this case you could customize magento functionality to bring this
feature back for youOn Wed, 20 Nov 2019 at 18:15, angelflo notifications@github.com wrote:
Hi again,
Thanks a lot but we choose Magento especially because it's modular and
allow this specific feature and we invest a lot in extensions + custom
dev
on this solution, now it's to late for us to switch on prestashop !
I really don't understand why Magento team remove it ... I can totally
understand that it can create security breach but in specific situation
it's really mandatory, this is why the solution where people can choose
to
enable or disable it (like this is the case previously) seems to be the
good solution.
I'm ok with you to disable it by default , but leave the choice to
enable
it if it's really mandatory for some specific case.
Also, thanks a lot for your suggestion with letsencrypt, but it doesn't
fit what we need for our business...
Please, leave the choice to people to choose by himself between high
security or medium ... this is exactly the same than if I block all
ports
on firewall ... i improve security but I can't use web server, if I
allow
traffic I add some risk but I can do business.—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAOJOUNHP7VBOJY2OHBWQSTQUVPDXANCNFSM4JPOZ4QA
>.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<
https://github.com/magento/magento2/issues/25663?email_source=notifications&email_token=ACL7K4T4OTHPG446UIG2Y7TQUVPIVA5CNFSM4JPOZ4QKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEESRZFI#issuecomment-556080277
,
or unsubscribe
<
https://github.com/notifications/unsubscribe-auth/ACL7K4STS7N4ECQNI2NG7TTQUVPIVANCNFSM4JPOZ4QA.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/magento/magento2/issues/25663?email_source=notifications&email_token=AAOJOUONZMU2QGB6UJSMRD3QUVPP5A5CNFSM4JPOZ4QKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEESR7YQ#issuecomment-556081122,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAOJOUID7UM2MSB4DXVMXPTQUVPP5ANCNFSM4JPOZ4QA
.
thanks for your reply ... i really hope that you'll take my suggestion in consideration and re-enable this feature on next update to leave the choice to your customers to manage their "risk vs feature" and not only destroy some things who work well since Magento 1 :-(
I can't invest again to re-anlayse and patch all the source code and create new problems after each update of magento because i use custom code.
It was so easy to have enable/disable with disable by default ...
Hi @angelflo,
Unfortunately it's not I did this decision to remove this option at all.
I even don't have details why it was removed, just know that it was as part of security patch, so it was removed because of some issue.
UPDATE: I wasn't correct, it was enabled by default. This code was removed as part of https://github.com/magento/magento2/commit/fe7fbce272c0c0fdd06b7eaadede0bd18cfe8212.
So you could review these changes and updated your code accordingly
Hi @engcom-Charlie. Thank you for working on this issue.
In order to make sure that issue has enough information and ready for development, please read and check the following instruction: :point_down:
Issue: Format is valid will be added to the issue automatically. Please, edit issue description if needed, until label Issue: Format is valid appears.[ ] 2. Verify that issue has a meaningful description and provides enough information to reproduce the issue. If the report is valid, add Issue: Clear Description label to the issue by yourself.
[ ] 3. Add Component: XXXXX label(s) to the ticket, indicating the components it may be related to.
[ ] 4. Verify that the issue is reproducible on 2.3-develop branchDetails
- Add the comment @magento give me 2.3-develop instance to deploy test instance on Magento infrastructure.
- If the issue is reproducible on 2.3-develop branch, please, add the label Reproduced on 2.3.x.
- If the issue is not reproducible, add your comment that issue is not reproducible and close the issue and _stop verification process here_!
[ ] 5. Add label Issue: Confirmed once verification is complete.
[ ] 6. Make sure that automatic system confirms that report has been added to the backlog.
Hello @angelflo @ihor-sviziev
I guess we can close this issue as non-issue & not actual.
Thank you for contribution and collaboration!
thanks for your reply ... i really hope that you'll take my suggestion in consideration and re-enable this feature on next update to leave the choice to your customers to manage their "risk vs feature" and not only destroy some things who work well since Magento 1 :-(
I can't invest again to re-anlayse and patch all the source code and create new problems after each update of magento because i use custom code.
It was so easy to have enable/disable with disable by default ...
Did you find a solution for your problem ? We are running into the same problem right now, after updating from 2.3.2 to 2.3.4.
@magento-engcom-team, @engcom-Charlie, this is a critical feature of Magento, it's probably one of the main features which still make Magento more feature-rich than other platforms.
This removal impacts almost every Commerce Edition Customer we maintain. Without this support, these customers have no reason to stay on Magento. This is a huge SALES issue, please fix it immediately!
Let me be clear, I'm not saying SID is the correct solution, however, there needs to be a feature to replace the ability to have shared carts across multiple domains for all users, not just logged in ones. This is e-commerce, what percentage of customers are logged in users in 2020... Maybe 15% or less?
We've come up with a solution which I believe is more secure then the standard SID param sharing.Â
When the user visits a page we make an AJAX request to a controller that gets the visitors session ID and encrypts it with the visitors IP address and a salt.
This encrypted string is then returned and appended to any cross store URL links on the page as a query parameter.
So when a visitor clicks a cross store url we check for this parameter and decrypt the string with their IP address as the key and then set the Session ID so the session is restored.
The encrypted string can't be decoded without the key, so it won't work for session hijacking as it can only be decrypted on the server with the IP address of the user as the key that generated it.
Hope this helps someone or does anyone see any problems with this approach?
Most helpful comment
We've come up with a solution which I believe is more secure then the standard SID param sharing.Â
When the user visits a page we make an AJAX request to a controller that gets the visitors session ID and encrypts it with the visitors IP address and a salt.
This encrypted string is then returned and appended to any cross store URL links on the page as a query parameter.
So when a visitor clicks a cross store url we check for this parameter and decrypt the string with their IP address as the key and then set the Session ID so the session is restored.
The encrypted string can't be decoded without the key, so it won't work for session hijacking as it can only be decrypted on the server with the IP address of the user as the key that generated it.
Hope this helps someone or does anyone see any problems with this approach?