Different response based on browser - wordpress

I'm getting a strange behavior in my stack that I don't know where to look.
Using WordOps default install on Ubuntu 18.04, running on a VM Instance on GCP.
WordOps installed Nginx, php-fpm, MariaDB, WP and Redis cache out-of-the-box.
Initially, everything worked just fine. Then, on my phone, I started getting nginx 404, but on my pc it works. Sometimes the initial page doesn't work, but if I go to wp-admin, the page loads normally.
It is more strange that, on some devices, it works, it others it doenst, returning 404 page.
I really don't know know what's going on.
Anyway, the URL is www.lindastore.co.jp

The problem was with Let's Encrypt SSL certificates. Not sure why, but clearing then re-issuing fixed the problem.

Related

local site redirecting to https and getting ssl error- nginx

I am not a backend server guy, mostly work the front end(design and Javascript work). So pardon my beginner questions/terminology. But I could really use some help! Due to covid I am working remote and this is just NOT my expertise.
I have 6 sites I work on locally via a local environment (Nginx, virtual box). Recently, out of nowhere 1 of the sites has started redirecting to an HTTPS version and it will NOT load on any browser due to "ERR_SSL_PROTOCOL_ERROR", so I can not work on that site as of now. All the other sites, that live in the same environment, load fine and are not secure versions.
I have looked at their config files and they are all the same. I don't understand how 1 site is NOW getting redirected to an HTTPS version, I never get into the Ngnix system to change things. And unless I'm missing something it's my local env so nothing could be introduced from the outside.
Questions: Can I just redirect it back to the HTTP version??? OR can I add some certificate to fix my "ERR_SSL_PROTOCOL_ERROR" error?
Any help or direction would be greatly appreciated and the gods will shine upon you.

Laragon Sites-Enables stopped working

I have been learning the Laravel framework and I used Laragon to get started. Laragon sets up my web server and my Hosts file so that I can access my work through the browser. Normally, I would boot up the server using the fancy "Start" button in Laragon and then go to the browser and type in "myFirstApp.dev" and my site would show up. Now I am getting an error in the browser that says "This site cannot be reached" (as shown in image1.jpg). How can I fix/diagnose the issue? Has anyone else ran in to this issue?
.
Found the answer to my own question. If anyone runs in to this same issue, here is an explanation. Google released Chrome v63 which forces all .dev domains to https. To fix this either enable SSL in Laragon or chance the domain extension your projects (.test for example). This will require changing your hosts and {Laragon Root}\etc\nginx\sites-enabled files.
https://forum.laragon.org/topic/761/chrome-63-now-forces-dev-domains-to-https/6

MAMP "Extras" Wordpress site causes error ERR_CONNECTION_REFUSED

In short, I can create a new MAMP Pro 3 host with success and then download and install Wordpress 4.0 via MAMP Pro's "Extra's" feature also seemingly with success (no errors, ) ...yet it doesn't turn out that way as the browser says, "Error code: ERR_CONNECTION_REFUSED".
Full Details: Hi, I've just installed MAMP Pro for the first time on Mac OS 10.9.5 with all the default settings, the WebStart page loaded in the browser, php looks to be running fine. The problem I'm having occurs when running a preliminary test of MAMP by trying the Extras feature and installing Wordpress 4.0. I get no indication that anything went wrong with the default install yet clicking the button next to the Server Name "Open the hosts web page in a browser"... I am greeted with an error in Google Chrome, Firefox, Safari, etc....
"This webpage is not available. Google Chrome's connection attempt to was rejected. Error code: ERR_CONNECTION_REFUSED
Google Chrome's connection attempt to testwpextra.dev was rejected. The website may be down, or your network may not be properly configured.
Check your Internet connection
Allow Chrome to access the network in your firewall or antivirus settings.
Check your proxy settings
"
I'm not using a proxy, I am running apache as my local user and have confirmed the document root is owned by the same user (with read/write permissions), I turned off firewall/littlesnitch just to be sure, same result in various browsers.
I read some fella saying something about setting up his host with IPv6 but I'm using the MAMP control panel to manage the process for me and don't see settings of that nature. Maybe this is done via the Extended tab with directory or VirtualHost parameters, I don't know... wish I did. Please help! Thanks!
I solved my problem by changing MAMPs ports from the default 8888 etc... to 80,443,3306 (on MAMPs General tab). Now all my includes are broken because MAMP doesn't allow "php_value" in htaccess files...one step at a time i guess. =]

HTTP restriction: oversized cookie

I recently deployed my application on heroku and I am getting a 502 error with description : HTTP restriction: oversized cookie
Found on Heroku :
Oversized cookies
The cookie in the response will be too large to be used again in a request to the Heroku router or SSL endpoints.
I have no idea on how to overcome this. I tried lots of advices from Heroku troubleshooting page without success.
Also everything works fine locally (setting a Python virtual environment and running foreman start).
Any idea ?
I found the solution by just looking at the response headers locally using Chrome devtools. I realized that Flask sessions are built on top of cookies which caused the oversizing issue (see here). I just got rid of it and now everything works fine.

ServiceStack google OpenID suddenly not logging in

Got a site still in dev that uses ServiceStack's Open ID implementation to sign in users. It's been working fine all this time, suddenly today morning Google's OpenID login started failing, Facebook still authenticates fine. No error is thrown, just redirects back to the default url with this appended to it:
#f=Unknown
On my localhost it works flawlessly, both Google and FB login ok, only in production does it fail. I have tried quite a lot:
Re-verified each and every file in my asp.net bin folder compared with local and production, no difference.
Re-routed the production domain name to my localhost (in the hosts file), in hopes to step through the creation of the session. No luck, still signs in flawlessly.
Connected via remote desktop to the server and tried logging in on it as localhost, fails. (yea, WTH?).
Is there a way I can get a log of what is going on as the authentication is happening? or does anyone have an idea of what could be the issue?
On a side note: I recently changed dns settings for the domain name and moved it to this new server, but that was around 3-4 days ago, and it's been working fine all this time, until today morning. Also noticed that a reverse DNS lookup on my IP resolves to a different domain, investigating that right now.
UPDATE
This issue reared it's ugly head again this morning. I'm not sure what could be causing it but I suspect windows automatic time synchronization to be somehow throwing things off. I'm turning it off and going to keep an eye on things to see if it returns. Also, this issue seems to throw my SSL settings into chaos, i have to manually reset IIS's SSL bindings in order for things to work, even WebDeply is affected. Very strange.
UPDATE 2
Issue happened again today. I'm now suspecting it's somehow related to IIS's web deploy feature cause it happened immediately after I published my site. Also now realised that I don't need to reboot, a simple iisreset seems to fix it. Will keep monitoring.
FINAL UPDATE
I finally found the culprit. Time. My virtual server was gaining time very fast and every few days it would be ahead of most other servers and so the authentication would fail. The limit seemed to be around 3-5minutes, within that range, the authentication works okay. More than that, it fails. To get around it, simply enable time syncing and it should not re-appear.
You can check your production server clock. The OpenID request synch with the internet time in order to validate the request. If the clock is off or it was off for a while just reboot and the problem will be solved.

Resources