That's my NGINX-directive for the last line:
location ~ (^|/)\. { return 403; }That's the Lets-Encrypt-Request that gets blocked:
http://domain.com/.well-known/acme-challenge/8ijNOjUvNUY22VbYPZbfDH3…I understand that this comes from the url path starting with a "." right after the domain but in order to modify my NGINX-rules in the best possible way I'd really like to understand what the original htaccess rule is trying to protect…
## Allow .well-known folder
RewriteRule ^\.well-known - [S=250,L]
S=250 redundant here because of L? https://httpd.apache.org/docs/current/rewrite/flags.html
Hi All,
We have a site which is selling magazines and we have used the "Storage" extension to keep the cart items until customers do the checkout. There're two payment methods available for the customer to choose.
1) Stripe
2) PayPal
Everything was working fine until last week, but we had to change the Stripe payments code as they are enforcing SCA in their new API. We have changed the Stripe payments code now and it has been tested fairly to assure that nothing brakes the transaction.
However once we released the changes to the live site we had few complaints that some customers were unable to perform the transaction. So we looked into the our log files and found that the transaction is failing due to the reason that some required information is missing. In each case we noticed that Storage data has gone empty before they complete the payment. Then we had a look at server log files and found that there's a fatal error related to MySql. The error as follows.
PHP Fatal error: Uncaught DatabaseException: MySQL Error (1366): Incorrect string value: '\xF0\x9F\x99\x82";...' for column 'session_data' at row 1 in query: INSERT INTO sym_sessions (session, session_expires, session_data) VALUES ................
This seems to be occurred by the Storage extension and we have no idea why this is happening (This has not happened very frequently). I'm not sure you guys are aware of this, if so, can someone please advice what we can do to avoid this error.
Thanks in advance
$str = preg_replace('/[\xF0-\xF4].../s', '', $str); (see http://stackoverflow.com/a/16902461).
Hi @michael-e
We were going through the issue as per your advice and found that it might not be the case. Let me first explain the workflow of the system.
1) Customer add items to the cart (Information will be saved using the Storage extension) then customer goes to step 2 which is another page
2) Then we suggest some other products to the customer in this page. If they like, they can add more and go to the step 3 (Information will be saved using the Storage extension)
3) We collect their personal (Billing) information (Information will be saved using the Storage extension)
4) We collect delivery details (Information will be saved using the Storage extension)
5) Checkout using Stripe or PayPal
In this last step when customer fill in the checkout details, it will first create the customer member account getting the data from Storage. What we have observed is that, when trying to create the member account the storage has gone empty (We have a log file that keeps the transaction info) sometimes (This happens rarely) causing to fail further execution (Causing to fail the Stripe payment). This issue occurred since we have changed Stripe to become SCA compliant and at the same time we have updated the Symphony core to latest (2.7.10).
So this is either our Stripe SCA code change or Symphony core or the Storage extension. We actually can't see why this is happening Michael. The only thing that we know is that Storage has gone empty in the last step before creating the member.
We really appreciate if you can help us with your expertise on this matter Michael as we're in a great deal of trouble as site visitors are complaining time to time they cannot perform the transaction.
Many thanks in advance.
\xF0), so I strongly assume that this sequence causes the issue.Symphony can not save 4-byte utf8 sequences to the MySQL database. Instead the original string will get truncated (which will result in an invalid session, probably). Debugging this will require logging the relevant data. So you must "hack" the extension and/or the core — the goal is to find/see data that do not work!
@twiro I still feel that the rule is good. But I always add this directive before Sym's one:
Interesting. I never had this problem with apache environments and the default htaccess-settings… so I'll try to keep that rule in my nginx-directives and also add an exception for the ".well-known"-folder before it. Thanks!
I found some infos and examples, but they all miss that aspect…
@michael-e yeah, we will replace it. But I would like to have a complete html export before ;) cc @animaux
Oh. But if it gets replaced, I hope we can keep a static version that is still accessible and fully searchable with Google – this website, as old(fashioned) and partly no more up to date it may be, is still the single best and most important source of information for my work with Symphony. Loosing all this structured and well searchable information without a proper replacement would feel like the final nail in the coffin of the once prospering Symphony ecosystem (Yes, I'm still not over it that this chat killed the beloved forum…)
Replacing the current website with something "sexy", that lacks the depth of information that the current website has, wouldn't make any sense in my eyes as long as the other parts of the Symphony ecosystem wouldn't keep up with that promised "sexyness" – just think of the default ensemble, which I see as a much bigger turn-off for newcomers in terms of "sexyness".