I have two question to which I can't seem to find clear answers.
(1) I have GA tracking set-up for my domain.com.
(2) I also have the same tracking code set in the <head> of some other subdomains: sub1.domain.com, sub2.domain.com, etc.
(3) The subdomains are protected with Apache's basic auth which requires to provide a username and a password to access them.
Questions:
Does GA automatically tracks traffic from subdomains?
Is it possible that GA still sends calls from auth-protected
subdomains?
Thank you!
While you have to set a domain name in the configuration tracking is not limited to that domain; Google Analytics tracks traffic from every domain with the given account id, be it domains and subdomains or different domains (except that sessions are interrupted if the user switches between domains unless you have set up cross domain tracking). So that is a yes, subdomains will be tracked.
Basic Auth prevents people from accessing your site, it does not prevent your site from accessing urls on the internet. The call to Googles tracking server is, at the end of the day, simply a call to some url. So yes, Google will still send calls from auth-protected (sub-)domains.
Related
Is there any way to use HTTPS/SSL on GitHub Pages sites that use a custom domain? SSL is recommended for better search engine ranking and there are a lot of other uses for it beyond that.
Custom domains on GitHub Pages do support HTTPS / SSL:
GitHub Pages has supported custom domains since 2009, and sites on the *.github.io domain have supported HTTPS since 2016. Today, custom domains on GitHub Pages are gaining support for HTTPS as well, meaning over a million GitHub Pages sites will be served over HTTPS.
https://blog.github.com/2018-05-01-github-pages-custom-domains-https/
Go to https://github.com/**username**/**repo**/settings
Check the checkbox "Enforce HTTPS":
Prior to May 1, 2018, SSL was supported by GitHub Pages only on sites using a *.github.io domain: https://help.github.com/articles/securing-your-github-pages-site-with-https/
It's now possible to use HTTPS on GitHub Pages sites with a custom domain
If you are using CNAME or ALIAS records for your custom domain, you’re all set and your site should be accessible over HTTPS.
If you are using A records, you must update your site’s DNS records with new IP addresses. Please see our guide to setting up your custom domain with Pages and update any A records you might have set.
Once you have HTTPS working:
You can optionally “Enforce HTTPS” for your domain in your repository’s settings, ensuring users who request your site over HTTP are upgraded to HTTPS.
You can read the full announcement here: https://blog.github.com/2018-05-01-github-pages-custom-domains-https/
I have 3 e-commerce websites having same contents on it,the domain name is same but the extensions of all domain is different.How to inform google that i'm the verified owner of all domains.
I just wanted to let google know and seek permission to use same content is different websites of mine, so that it wouldn't affect my ranking.
Is there any code by putting which on the 3 sites, google will got to know that these same sites are of one company's????
By "the Domain name is the same but the extensions are different" i guess you mean you have example.com, example.net, example.io.
if this is what you mean, these are considered to be three different domains. you should implement canonical urls including the preffered domain or redirect all traffic to what you consider the main domain. (e.g. redirect traffic from example.net and example.io to example.com)
For each domain you should use a txt recod to verify ownerhsip in the webmaster tools, most domain providers allow you to configure this record for each domain on your own. Log into your account at your domain provider's site and search for DNS Management, Name Server Management, Control Panel, or Advanced Settings.
Then again, many CMS or e-Commerce systems support "website aliases", where you can configure your system to answer to different domain names, when all your domains point to the same server and often allow you to configure a canonical domain, so that you may even not need to run 3 identical websites.
Please specify your setup, there is not much to go on here. A good example would be:
I currently run 3 Websites (example.com, example.net,
example.io)(Drupal) on 3 Servers, each has its own domain but they
have identical content. They do not use a shared database.
I currently have a landing page setup on my domain.com which already receives traffic.
It will shortly be replaced with an online store. I need to upload this store to my live server in order to get it approved by the Merchant Facility Providers (MFP), and they require it to be accessible from it's final live location on domain.com in order to get approvals. I can't have users access this site until it has met approvals.
To accomplish this I wish to redirect all domain.com traffic to domain.com/holding/ except for MFP visitors.
Ideally this would be restricted by IP address, however MFP say they will need to grant a number of external parties access, and so IP address based access will not be acceptable and I should use passwords.
So my question is, how can I automatically redirect all traffic from domain.com to the holding page domain.com/holding/ unless they have logged in using a password at domain.com/login?
Users visiting the domain.com should not be asked for a password.
Will this be possible using just .htaccess/.htpasswd?
If so, can someone suggest how the logic of how it could work?
It's not possible using just an .htaccess file as all visitors would be presented with an HTTP standard authentication dialog if you enabled it on your domain.com site at the doc_root level.
Without knowing what scripting language you're using? (you've not indicated in the tags, just apache), but you could provide one index page that both acts as a landing page for users/potential-users as well as provide a login (username/password form) for MFP parties (wherever they may come from).
That way, you fulfil both needs without offending or discriminating in any way against any party.
As #nickhar has pointed out, there appears to be no way of doing this using just .htaccess.
My solution was to use a rewrite rule to redirect all requests from domain.com to domain.com/holding unless a specific cookie was set (checked for using RewriteCond %{HTTP_COOKIE}).
I set this cookie in a php script on domain.com/login, which was password protected using .htaccess/.htpasswd.
This is by no means a particularly secure solution, but is adequate for my purposes of keeping the site hidden from general traffic while the approval process is completed.
Whenever I login to one Google service, I am automatically logged in all their other websites on different domains.
What I want to know is how they are able to access the disparate cookies and sessions that belong on another domain.
I tried searching online but I couldn't find any information. I could probably pull out firebug and try to find out but I am sure someone here knows.
A Google Login works like this:
1) You login, normally at a login page that is under the Google.com/accounts domain.
1a) If you aren't on the Google.com/accounts domain, it is going to forward you there after you post the form. This can be found on sites like Blogger.
Once you arrive at the Google.com/accounts domain, they do two things
2) They set a cookie(s) that is specific to the Google.com/accounts domain, that are also only able to be sent over a secure connection. This is to verify your identity later on.
I say multiple because there are several cookies bound to the google.com/accounts domain. I believe that one of these is to make sure that all doesn't fail if secure connections aren't allowed
3) They set a cookie that spans all the domains using .google.com as their domain, because this will make the cookie available to any domain.
4) They forward you back.
5) If it is a site on a different domain, like blogger, they send along an authorization key in the URL. The page sees it, verfies it, and sets the cookie for a different domain. A technique like this can be seen using Google's Oauth.
Here is where that Secure Cookie comes in.
If you notice, whenever you go to a site after you close your browser, they forward you to the google.com/accounts path, where they reverify you under a secure connection, and then reset the subdomain-wide cookie. Then they send you back.
Furthermore, some sites like Google Adsense use the same technique as Google.com/accounts uses, by making a secure cookie on a specific path, and then using more global cookies to allow greater access.
Some of this is guessing, but given what a non-insider can see, I believe that is close to the truth.
Note: I literally spent like an entire month just browsing from Google Site to Google Site seeing how they did stuff. By upvoting this post, you are decreasing the sadness I have for having no life
I have a domain and a group of sub-domains that require authentication to access. I am currently using mod_auth to authenticate users (mod_auth basic) at the domain.tld level. My goal is for single sign-on between the domain and all the sub-domains.
Will these credentials carry on to the sub-domains automatically, or with a simple vhost config change, or is there a better method to do this?
mod_auth_basic
Browsers distinguish areas that require HTTP authentication by a combination of the URL root and the name of the authentication realm.
Take for example, two domains each with a realm with the same name:
http://one.example.com/ with the realm "Please enter credentials!"
http://two.example.com/ with the realm "Please enter credentials!"
First a user visits one, is asked for credentials and enters them. Then the user visits two, the browser recognizes that the URL is different and thus asks again the user for her credentials.
This is a good thing, because otherwise www.badguy.com could set it up so that your browser sends over your online banking login.
In short: there is no way to solve your problem with basic HTTP authentication and standard HTTP clients.
mod_auth_digest
You could use mod_auth_digest instead, since with that you can specify more than one URI to be in the same "protection space". However, with this authentication method there are two new problems:
It doesn't scale very well, because you cannot use wildcard domains.
Browser compatibility is not as good. (See the documentation on how to make it work with IE.)