I have a website on a cloud server running Windows Server 2019 + Apache + PHP + MySQL. I use phpmyadmin to manipulate the database. Everything worked fine for nearly a year till few days ago I made the web service run through Cloudflare. The website itself is still working normally but later I find that phpmyamin has some problems. It shows blank page, which should be a login page, when I use the same link I used before to open it. Then I find in Chrome's developer tool the following message:
Refused to load the script
'https://ajax.cloudflare.com/cdn-cgi/scripts/7089c43e/cloudflare-static/rocket-loader.min.js'
because it violates the following Content Security Policy directive:
"script-src 'self' 'unsafe-inline' 'unsafe-eval' ". Note that
'script-src-elem' was not explicitly set, so 'script-src' is used as a
fallback.
After searching for the cure for hours I still do not get a clue. Could someone please share your remedy? Thank you very much!
You did not just change NS to Cloudflare(CF), you do pass all traffic via CF (observed orange cloud not gray in the CF opt).
Therefore CF injects some scripts into your page:
Rocket-Loader.js (this one causes you issue)
Mirage.js Pro, Business, and Enterprise level domains only
BrowserInsights.js to collect some metrics
Therefore you need to modify your CSP accordingly or do traffic bypass CF (make cloud gray and use CF as DNS server only).
Be careful with CloudFlare it brings a lot of surprises (enforced caching for example)
Related
I have a software based on Java HttpServlet, which I cannot modify in its source code.
This software sits behind an SSL enabled Apache Server with a VirtualHost.
When accessing a webpage, JSESSIONID cookies are set for different Paths.
This works fine as long as I am connected to the same network as my server.
When accessing the server from outside of the local network, a counterpart for each JSESSIONID cookie is created with a HASH_ prefix, resulting in many HASH_JSESSIONID cookies.
Additionally, my session is lost/destroyed mid-request when accessing the server from outside, resulting in unwanted Java code to be executed.
I suppose that the creation of these HASH_JSESSIONID cookies is somehow linked to the loss of my session, thus resulting in an unstable user experience.
The only difference between both cookies is that the HASH_-cookies are SameSite:"None" and the original-cookies are SameSite:"Lax".
Editing the cookies through Apache via Header edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure;SameSite=Lax only results in the original-cookies to be edited.
Has anyone had any experience with these HASH_-cookies and can point me in the right direction, to e.g. prevent their creation?
Cheers!
Dig, wget, nslookup and curl commands work perfectly for a specific URL I have pointed to another server less than 24 hours ago.
Problem is, it just refuses to be resolved by the browser (Chrome, Safari and Firefox). The strangest part is that it is being successfully resolved by Postman (by testing the OPTIONS and the GET methods separately), but still doesn't return a proper response on the browser side of things.
DNS checks are returning positive, so this is when I started suspecting that the problem is actually within the headers of the HTTP protocol's requests which are sent - alongside the fact that different responses are being returned for the requests that don't include the default browser headers (being issued through the different command-line tools & Postman) and the ones who do (being issued by the browsers automatically or manually using the dev tools).
After fully flushing the current local system's DNS cache, including the browsers's and even trying another device on another network - I still get still no response on the browser.
Kept going, and attempted to verify that with a VPN (locally - which didn't work), and an online web proxy tool (which did work).
Finally, I extracted the router's default DNS server address, used nslookup to look up the URL again, this time specifically mentioning the desired DNS server (the one stated above), and after getting a successful response with the correct values, I am now pretty much sure the HTTP request is causing the problem.
The URL is hosted on Amazon S3 Static Hosting option, which I used many times before, and didn't have a problem with, with that exact same configuration. Looking up the recent changes/features that were possibly added, pointed out that I may need to explicitly set a CORS policy for the newly created bucket, on top of the usual public access policy that is needed.
After applying that as-well - it still doesn't seem to work.
As a quick change in direction that may possibly make some parts clearer about what's going on (and as I started to think that the browser might not be getting the correct Content-Type header in the response, which should be text/html header as its response, and therefore, possibly doesn't resolve the URL with the expected behavior), I went ahead and applied a 301 redirection on the S3 bucket, instead of the static files hosting, and again, it all works perfectly through the command line tools, but not through the browsers.
Anyway, the browser just doesn't seem to complete any of the requests being sent to the URL.
That might be the OPTIONS pre-flight request failing to respond correctly, and the browser just doesn't continue to issuing the GET request, or the URL is not being found by the DNS route the browser is taking, which is unclear to me currently if that is the option.
Any ideas? (besides the fact that sometimes it just takes longer time for some DNS servers that happen to be on the chosen route to update/refresh their cache, which doesn't appear to be affecting my local machine's DNS route specifically for this case. That, being said with caution, was verified by validating the different parts of DNS configuration and prioritization throughout the different possible parts on my system (Mac OS X), including the fact that the response gets back with the correct address successfully).
Found my answer here:
https://serverfault.com/questions/942030/aws-s3-static-hosting-how-to-debug-connection-timeout
As linked there, more details can be found here:
Non-Authoritative-Reason header field [HTTP]
Solution & Explanation: Because of the nature of the domain extension I have purchased (.dev extension) Chrome was silently using HTTPS because of the URL being part of Chrome's HTTP Strict Transport Security (HSTS), because all .dev domains should be using HTTPS only. Therefore, the issue was still showing up, even when explicitly typing http:// into the URL address bar.
This can be overridden by applying a CloudFront distribution with HTTPS support on top of the S3 Static Hosting, as usual (but still, it should be noted as HSTS listings can cause that for different cases, including this one as part of them, because of the .dev domain extension).
Useful Resources (for debugging purposes)
In addition to what is stated here:
https://gist.github.com/stollcri/7c09bafc97223481920e
You can issue a lookup query (and also add or delete your local set of HSTS listings) through the following Chrome's settings URL:
You can also check the current listings here: https://hstspreload.org/
Bit of a strange one - Over the weekend I updated the version of PHP on one of our servers and all seemed to be working fine, however yesterday, we started to receive complaints that the site was down.
After looking in to it, the site works fine when connecting from the internal network, but it times out when trying to connect from an external IP address.
Server admin isn't really my strong suit, so not really sure where to begin. I've checked the httpd.conf files and all looks fine, the apache config test reutrns 'OK' so at a loss as to where to go next.
Server is running Centos, PHP 7.2 and apache 2.4.6.
How can I get the server to respond to external requests?
Andy
You can use this tools (metod) to check where is propably the problem:
I. on serwer, check :
whether is serwer conections to internet - ping, tracerout
whether page is loading (on local) - lynks, links (text web broweser)
whether your dns is working (or dns ISP prowider) - depending on the service used, e.g. BIND (check usage this tool in internet)
whether your firewall is ok configured and good work - depending on the service used e.g. iptables
whether domen settings is ok,
...
II. on computer, check: (in internet, not in local network with your serwer)
whether the website loads in the browser eg firefox after using ip address (your server where the page is located) in www bar
whether host in internet have a contact with your serwer - ping, tracerout
whether the website loads in the browser eg firefox after using ip address (your server where the page is located) in www bar
...
The problem is wery complicadet becouse I dont now what exactly you have an infrastructure and it is settings (network, ISP, etc.) which you on host the page you are writing about. For this reason, it is difficult for you to precisely help.
I am trying to set custom domain for my Firebase app.
Firebase hosted url : https://inventory-app-726af.firebaseapp.com/
Custom Domain: inv.agsft.com
I have followed all instructions as part of setting custom domain but after verification step when I click on finish button, status will always be "Needs Setup".
I am managing DNS through cloudflare (https://www.cloudflare.com/) and I am following Quick setup option.
Any pointers to resolve it?
I had the same problem, I was able to resolve it by toggling the DNS Status on cloudflare from DNS and HTTP Proxy (CDN) to just DNS on the two A records
It started working right away.
The proper solution, ie without disabling Cloudflare for the site, is to use Full SSL for your domain/subdomain.
You can either choose Full SSL for all your domain entries, or set up a Page Rule for a specific subdomain, in your case, use "inv.agsft.com/*"
Source: https://community.cloudflare.com/t/flexible-ssl-redirect-loop-with-google-firebase/2063/3, which in turn points to https://support.cloudflare.com/hc/en-us/articles/115000219871-Why-does-Flexible-SSL-cause-a-redirect-loop-
Had the same issue and this solved the redirect issue. Firebase will however still report the domain as "Needs setup", for that I have no solution, but it does not affect the functionality of the hosting.
For the people that is using Namecheap, This configuration worked for me.
To avoid any kind of ssl issues when using firebase hosting and cloudflare you have to check to following points:
You don't need to toggling the DNS Status on cloudflare from DNS and HTTP Proxy (CDN) to just DNS on the two A records unless you don't want the cloudflare ssl certificates and want to just use the firebase ssl certificates (look to this carefully because you will loose the protection that cloudflare provides to your site in case you decide to use only the clouflare DNS)
If you "keep the cloud orange" it will not causes any problem to your firebase hosting.
Add the firebase IP's to cloudflare following the instructions provided by firebase hosting and remove any other A record from your domain/subdomain that you are setting up
To ensure you have a end-to-end encryption (using both firebase ssl as well as cloudflare ssl), make sure that your cloudflare crypto options is set to "Full":
Use a page rule likes in case that you want your root domain to receive all trafic:
In your firebase hosting setup, do the same:
p.s: Look that the message "Needs setup" is still there but the app is running without any problem.
p.s2: the majority problems regarding cloudflare and firebase is that firebase ssl can take several hours to start to work and you keep seeing a message like "your connection is not private". It happens not beucase cloudflare is messing our proxy out but because firebase ssl is still not fully propagated.
I hope it help others :)
In my case I did the same that Brennen did:
toggling the DNS Status on cloudflare from DNS and HTTP Proxy (CDN) to just DNS on the two A records.
But just start working when I:
Delete the domain from firebase. (click on the : points select delete domain)
refresh the firebase site
Added again in Quick Setup. I already had the A record added in Cloudflare so I didn't added again.
After that automatically the status added was connected.
Remember: Before testing, clean your browser cache.
When I run dig -t txt +noall +answer inv.agsft.com there are no TXT records showing. Since those are required to verify your ownership of the domain, Firebase Hosting will not continue the setup beyond step one.
Update: since the next step requires you to map A records to the IP addresses of Firebase hosting, I ran the relevant dig too:
$ dig -t a +noall +answer inv.agsft.com
inv.agsft.com. 299 IN A 104.18.56.240
inv.agsft.com. 299 IN A 104.18.57.240
Those are not the addresses I'd expect for Firebase Hosting, so it looks like either you haven't correctly entered the A records, or they have't propagated yet.
When I change my setting like below, it started to work again.
Redirect loop fixed:
For GoDaddy this adding the following solved it for me:
TYPE:A
NAME:#
VALUE: your ip_1
TYPE:A
NAME:#
VALUE: your ip_2
June 2020
Just wanted to share what was successful for me. It was a combination Brennen and Lisbel's answer.
Step 1: Toggle off your DNS status to get a grey cloud (as shown in the earlier answer)
Step 2: Delete the domain from firebase
Step 3: Add it back with Quick Steup
It should be connected after these steps!
I had the same issue. Here's how I fixed it:
1) Cick the View button on the problematic domain (in the Hosting section next to where it says Needs Setup).
2) Change the 'Setup mode' from Quick Setup to Advanced and follow the 3 steps
2a) Open your domain provider's settings (I'm using Google Domains) and add the TXT record it's giving you.
2b) Wait about 4-12 hours for verification
2c) Add the provided A records into your domain provider's settings
This is not a quick process, but it should be working about 5 minutes after you complete step 2c.
Toggling DNS mode didn't work for me. So I tried following approach and it worked for me.
Add CNAME record pointing to {firebase-project}.firebaseapp.com or {firebase-project}.web.app, you could add A record and try.
ADD TXT record as firebase ask you
Verify from firebase (this will show as needs setup, also it didn't go away although this worked)
If new domain/subdomain doesn't works check your browser developer tools network tab. If there are lots of 301 happening then go to cloudflare page rules. Add newdomain.com/* or subdomain.newdomain.com/* then add settings select SSL and set it to full as follows.
Then it will work as expected.
Working as of 11st May 2022 without need to toggle DNS and HTTP Proxy (CDN).
Steps:
Go to Cloudflare Dashboard.
Select SSL/TLS.
Select Overview.
Select Full option for SSL/TLS encryption mode.
After that, refresh your website that previously have issue to access.
Now the website can access successfully.
My client is seeing a different version of the website on his computers then what I am seeing on mine. He claims to be deleting the cache. I'm using Safari with the cache disabled via the Develop menu and I see the correct version of the site.
Is it possible that the website is somehow cached by my client's ISP or something along those lines?
Update:
I think I need to describe the problem better:
My client has a web hosting package where he has his domains and email accounts. somedomain.com has it's A record changed to point to Behance's ProSite hosted service.
The problem is that when he goes to somedomain.com he gets the index.html that's sitting in his web server's public_html directory, and not his ProSite. Using the same domain I see the ProSite. He has cleared his cache and tried on a computer at home with the same result. This is what lead me to believe that there is some sort of caching issue somewhere along the line with his ISP(s).
Is there anything I can do about this?
Proxy servers at the ISP or even the client's site might do this. Or even network-compressors in some (mal)configurations.
Depending on the site you might also be seeing actually a different site. e.g. Google redirects to different servers using DNS load balancing.
Yes, you're right. To improve performance and the speed in loading page from the same request modern browser seem to great at caching. I myself have the same problem as well. To resolve this problem You should tag version of your projects whenever you deploy them to production.
Based on the update, the problem was with DNS cache.
DNS can be cached at the following levels:
browser
operation system
router
DNS provider
And each of them has its own way to flush DNS cache. Except DNS provider where the only thing you can is to wait for cache invalidation. Though you can replace your current DNS provider with another one who won't have your domain in his cache. You have all the chances to find such if your domain isn't popular.