I'm trying to connect Printful service to my Wordpress website and I getting 403 error. After some search I found out similar issue rised by Printful devs (https://github.com/woocommerce/woocommerce/issues/10678) and it seems like nginx settings on the host I have my website is too strict. It doesn't allow urls like this as it has url as a parameter: http://example.com/wc-auth/v1/login?test=http://google.com
I've reached out Printful devs and my hosting provider, but both of them don't know how to fix it. I don't want to change hosting provider, so looking for a solution.
Does anyone know what ninx settings are responsible for urls as parameters being blocked?
Related
Website Unavailable
The website you are trying to reach is unavailable because it use security service to prevent unauthorized access and online attack.
No information in the Cloudways KB - a broad search returned nothing so I'm adding this here for others.
Hosting provider says: This is a new security feature that is recently added to avoid domain mapping attacks on the websites so server will not serve a website if the domain name is not present in the Nginx domain relevant file.
To fix, in your cloudways hosting account:
Choose the application experiencing the error message
Choose ‘Domain Management’
Make sure ‘primary domain’ value is set, if it IS, (as it was in my case), change it and change it back - I added the www. to mine then went back to my preferred domain name without the www. That fixed it for me.
I am using wordpress social login 2.3.3 and enabled yahoo, twitter and facebook. But in my infrastructure i am using nginx for hosting webpage and there is another instance of nginx used for load balancing the traffic. My domain is registered and i am using non-standard port for HTTPS.
My issue is when after entering the Yahoo credentials by credentials are getting successfully authenticated and when hauth.done=Yahoo gives me sent an invalid response ERR_INVALID_REDIRECT
As per the code in wsl 2.3.3 author has already taken care of non standard port. So the issue seems to be narrowed down to Nginx configuration.
Please help!!
This is mainly because of below wrong parameters posted in general
redirect_to
baseUrl
In general it means with respect to HybridAuth that you are not landed on right page.
As you said that you are using Nginx as loadbalancer and server. You need to check your server request attributes.
You should look for
HTTP_X_FORWARDED_PORT
SERVER_PORT
HTTP_HOST
HTTP_X_FORWARDED_HOST
There can be other parameters as well, with all these attributes plugin forms correct URL.
Hope that Helps :)
ERR_INVALID_REDIRECT is caused because your redirect url in developers.yahoo.com and redirect url in plugin does not match. Try to configure them identically.
I'm developing a website using ASP.NET identity that will work with subdomains that identify a client using some information from here I've got subdomains working locally, but I can't get it to work with OAuth.
For example, if I got to https://localhost:44301 and try to login with Google, everything is fine. In my Google console I have https://localhost:44301 under "Authorized JavaScript origins" and https://localhost:44301/signin-google under "Authorized redirect URIs". But when I go to https://foo.localhost:44301 Google will respond with:
Error: invalid_request
Invalid parameter value for redirect_uri: Non-public domains not allowed: https://foo.localhost:44301/signin-google
When you try to log in. I can add https://foo.localhost:44301 to "Authorized JavaScript origins" in the Google console, but it won't let me add https://foo.localhost:44301/signin-google under authorized redirect URIs because it will complain:
Invalid Redirect: https://foo.localhost:44301/signin-google must end with a public top-level domain (such as .com or .org)
Some other questions and answers suggest redirecting all subdomains to a single domain for OAuth, but ideally I want to keep logins per subdomain. So if you use google to sign it to foo.mydomain.com it will be separate from bar.mydomain.com and I don't think that'll work if I have to redirect both to the same single domain (although I'm not sure that's going to work without separate projects in Google.
Google and in general other OAuth2/OIDC providers will support redirecting to sub-domains. Your specific problem is that you seem to be trying to use sub-domains of localhost which is in the list of Special-Use Domain Names (RFC6761) and it seems Google has additional constraints for those ones.
However, this is not a real limitation because on production you'll use a public top-level domain from from where you'll have the specific sub-domains.
If you need to have this working for local development, you can use localtest.me which allows you to set a sub-domain you like (foo.localtest.me and bar.localtest.me) while still ensuring that the domain resolves to your local machine (127.0.0.1). This should stop Google from complaining about it...
Recently I added SSL to my WordPress site but it started causing some problems (conflicts with Woocommerce and WP Super Cache plugins). The problem the I was having because of SSL was that the the Woocommerce cart was sometimes showing empty even after adding a product ans sometime the cart was not proceeding to checkout page. Do you think it had something to do with WP Super Cache or SSL or both? Anyway, I couldn't get it solved and removed the SSL after 2 days. But meanwhile Google had indexed the HTTPS URLs of my site and was showing them in the search results and they were returning SSL connection error. Now my question is how can I redirect all those HTTPS URLs to the HTTP ones? I asked my web host for help but said the redirection is not possible through htaccess or any other method. Was he right? How long will Google take to 'forget' these HTTPS links and show the HTTPS links again in search Results?
There are two standard ways to redirect:
At the DNS level
At the HTTP level
The DNS level can't help you because it just changes hostname. You want to keep the same hostname but change the scheme. This means you need an HTTP server to do the redirect.
In order to redirect from https to http you need to have an HTTPS service running on the computer with the IP address that the hostname resolves to.
Without that, there is nothing the receive the HTTP request over SSL and response with "Oh, this has moved to plain HTTP".
If the SSL service isn't running, then there is nothing that can do that.
(.htaccess is just a (suboptimal) means to configure an HTTP server, that does no good if you don't have the HTTP server listening on SSL).
Personally I'd fix the https issues. The world is going more https everyday so it's a backwards step to go from https to http. If you elaborate on what issues you had someone might be able to help.
However if you really want to do this then you need to run both http and https and redirect all traffic from https to http. How you do this depends on your set up (in Apache you'd do it using htaccess config).
How long it takes Google to fronded your site depends on many factors including the size and popularity of your site - which governs how often Google crawls your website. Give it a month at least for a small site. You can give it a kick by submitting your site to Google Search Console (the new name for Google Webmaster Tools).
Btw StackOverflow is primarily for programming questions so questions like this might be better asked on the http://webmasters.stackexchange.com sister site.
Google Analytics recently started showing PHP scripts as referrers to my website, for example:
localhost/index.php
EDIT: This is a recent surge in activity coming from India. It is not coming from our own services, such as our web host, or a backup service. It is also coinciding with spam users on my websites from India, so I know this is intentionally malicious behavior.
Any suggestions on how to investigate further and prevent it? We are running on Django, hosted on AWS, if that helps.
If the server have subnet or the server is on your system it may cause that kind of referrers if request from the subnet.
Well, In case of Django if somebody from your team is running a development version of your application with the Google Analytics tracking code, then things like this can show up. Not only will localhost show up in your Referrers, but your aggregate metrics like Bounce Rate, Time On Site, Conversion, and others will be incorrect because the unusual behavior of a developer's will be mixed in with that of normal users and skew our results. There are basically 3 steps to fix it :
Add a Google Analytics exclusion filter
1) Open Google Analytics and choose your property view.
2) Navigate to Admin.
3) Click on Filters under the View column.
4) Click on New Filter.
5) Create a new "Predefined filter" which excludes traffic to the "localhost" hostname.
Edit: Configure ALLOWED_HOSTS in Django settings
This is a security measure to prevent an attacker from poisoning caches and password reset emails with links to malicious hosts by submitting requests with a fake HTTP Host header, which is possible even under many seemingly-safe web server configurations. Django 1.5 introduced the allowed hosts setting that is required for security reasons. A settings file created with Django 1.5 has this new section which you need to add:
ALLOWED_HOSTS = [
'.example.com', # Allow domain and subdomains
'.example.com.', # Also allow FQDN and subdomains
]
Add your host here like ['www.antodominic.com'] or ['*'] for a quick test, but don't use ['*'] for production.
Hope this helps ...!!
Cheers.. :)
If you have a website that is externally accessible, then yes- someone is trying to hack your website... and every other website in existence. It's a fact of life.
Your localhost referrer is not necessarily indicative of malicious behavior, however. It's more likely that your dev instance, or someone else's dev instance of their site with links to your site, is creating the entries in your analytics.
However, if it's a referer with a link to another site in the querystring, then what you're falling victim to is referer spam attempts. If you want to prevent them, you can block them via htaccess if you're running on Apache, or via web.config if you're running on IIS. Just replace the pertinent bits regular expressions, or better yet, add to them.