We have Urchin installed for the server statitics. Our server has an intranet subdomain (of course, banned to the outer access). When I look for the referal of any intranet page, I found that almost half of the access are from "direct[(none)]" and "google[organic]":
"direct[(none)]" access includes bots, direct keyboard access,
pdf/documents links... and all of these have the acces banned, and
"google[organic]" access are done through the serach engine
that can't acces to index the page nor redirect to that
So, I must conclude that the statistics of Urchin are not faithful.
Can anybody confirm that terrible conclusion? Or can anybody explain and correct it?
There are several ways to install Urchin. In this response I assume you use the tag method.
Urchin will create traffic sources based on document.referrer, it doesn't guess, it uses real data.
When you install Urchin one of the options you need to set is the domain name. This setting is used to store a first party cookie that will hold session information including referral info.
Let's say your intranet site is intranet.mycompany.com, this subdomain is private to your network but maybe the cookie setting in Urchin is set to mycompany.com, this will create a cookie in that domain and this cookie will apply to all subdomains.
Maybe this hostname has other subdomains, some that might be accessible outside your corporation and since they share the same cookie, they will share the same traffic source as well.
google/(organic)
Imagine this scenario:
User Looks for Company in Google
User arrives at the main public site at www.mycompany.com. Urchin registers this as a new visit from google/(organic).
User opens the intranet website
Urchin uses the same cookie and this is seen as a continuation of the visit that already has a traffic source
Urchin just reuses the google/(organic) traffic source defined in the cookie.
Also Urchin can share cookies with Google Analytics, so if you are not using Urchin, but instead Google Analytics the scenario above is also possible.
direct(none)
Now about direct/(none). This is used everytime urchin can't determine a better traffic source. In other words when the javascript variable document.referrer is empty.
This can happen in a variety of moments, including but not limited to:
Clicks on a pdf document
Clicks in a Microsoft Office document
Directly typing the url in the browser navigation bar
Clicking in a bookmark
Going from an HTTPS to an HTTP webpage
Related
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.
I have a share point website running on a server, and have a asp.net website that that is configured to run attached to the share point site. This this not exposed as a domain site( i.e. with .com or .in or .nl etc), i access this site in my development and test environment using a URL something like
https://www-dev-myname.domainname.local/
In google analytic i am not able to add this as default URL for an account, it does not allow me to save it.
Is there a way i can create a account with a URL of this type and setup analytic for my site.
You can simply enter a valid url - it does not need to be that actual url of your website, the only consequence is that you cannot user inpage analyses (that and the little icon in the page content report that allows you to launch a url in a new window).
Wrong domain name nonwithstanding Google Analytics will work on any domain where it can set a cookie (and if it can't you can set the cookie domain to none, in that case you need to provide a client id yourself to maintain session tracking).
Environment:
Server 2008
IIS 7, integrated mode
.Net 4
ASP.NET WebForms Routing (which uses the same .dll as MVC routing, though I'm not sure which version)
Cookieless sessions (session ID travels around on the user's URL).
We have an application that uses routing to identify which organization a user is associated with. The URL will take the form domain/Organization/OrganizationSubCategory. The user follows their custom URL and sees a landing page. When they hit next, they are directed to a page that collects some demographic info, then they hit next to proceed to the application. When they do, the user is added (if necessary) to their organization in our database. After the initial landing page, routing no longer applies - the user is directed to regular aspx pages.
The site is receiving a fair amount of users entering the app; an average of 850 per day.
The problem is that a small number (less than 1%) of users are getting added to the wrong organization.
We are logging information on the landing page and when they submit the demographic page. One thing we log is Request.RawUrl. We started noticing users who are associated with one organization being logged as having requested the full correct URL (including the sub-category) of another organization. Sometimes nobody legitimately came in following the incorrect organization URL even in the same day. We've had people report directly that they just created the "sub category" (using an administrative application), instructed a user to follow their unique URL, and yet the logs show an entirely different URL for that very user (I know it's that user because I'm logging email address and session ID so I can associate the same user's path through the landing page and the demographic page). It's as if IIS is sometimes creating a new session, and simply assigning some previously requested URL to that user.
In an attempt to eliminate some sort of caching, we have:
Set the config httpRuntime element's enableKernelOutputCache attribute to false
Disabled caching in IIS settings
Set the config sessionState element's regenerateExpiredSessionId attribute to false (even though we haven't seen the session ids being re-used).
Other suggestions?
Are these internal users? Are there proxy considerations? That wouldn't explain a wrong url though. Are you 100% certain the users were given url A and they show up with URL b? Do you have any routing modules currently assigned? Are you sure its not getting rewritten by a rule in another module?
Could this be an application issue where their 'new user' email (for ex) contains the wrong url?
Well, we still don't know with complete confidence, but it seems that users in one organization were most likely searching the Internet to find URLs into the system and following those.
I can't explain the report we had as I described in the original post.
When I tried to enhance logging to capture pre-post session creation to prove it for sure, the logging on the begin request event worked in our QA environment (same as production), but just flat wouldn't work in production. I could never determine why.
I have a sharepoint webpart where I have links to go to different web sites to which login is required. Therefore, I think i need to log the users on before redirect them into deep pages in that site, therefore I think i need to set up a cookie to that web site when the web part is loaded (by using the user credentials of the user's active directory information).
How can I achieve this requirement with out opening up a new browser window? (Though I have used a client side script, it pops up a new browser window)
Any help is highly appreciable...
Thanks
If you are referring to "different web sites" as sites having completely different URL's, then it's probably not possible without SSO system.
The reason is that it's impossible to read/write cookies from other domain in web environment, i.e. pre-login the users like you are saying.
If all the sites are inside same domain, like mycompany.com for example, and different sites are in abc.mycompany.com or mycompany.com/subsite, then yes, you can set the cookie. See top section here http://www.15seconds.com/issue/971108.htm
A simple way to implement SSO is by implementing method described later on in same article.
in the "Requesting Cookie from Another Domain". This is not a very secure method though, but can be done if you restrict it properly to specific slave domains. And obviously all the slave sites have to be modified, as with any SSO implementation.
We have a scenario whereby we are hosting an ASP.NET MVC web site on behalf of someone else.
The customer in this case wants us to restrict access to the web site, to those users who have logged in to their main portal. They should then only be able to get to our web site via a link from that portal.
At this point I'm not yet sure what technology or authentication mechanism the 3rd party are using but just wanted to clarify what the possible options might be.
If we call our hosted site B, and their portal web site A,as I see it we could:
Check the referrer for all requests to B, unless they've come from A they can't get in
Check for a specific cookie (assuming A uses cookies)
I'm sure there are other options, anyone any ideas?
Check the referrer for all requests to B, unless they've come from A they can't get in
Can be faked, but most normal users won't do it.
Check for a specific cookie (assuming A uses cookies)
Ask them to embed in their portal some code portion from your site. This way visiting their portal will resulting in you setting a cookie for your domain. Then you can easily read it later.
One more thing to mention. If you're talking about public sites, then it will suffice for a search engine to somehow discover these hidden urls once, after which the game is over. It will index the pages and keep a cache of it. You may want to consider including some noindex/nocache meta tags in these pages.
But seriously, if you wish to have it done properly and secure, you're going to need some form of shared user authentication that that portal and your site both support.
The solutions you have posted are not secure.
In case this is an enterprise application with real requirements for security, you may want to look at some single sign-on solutions.
List of single sign-on implementations