Develop Reference

Getting user info using Client ID

I have inserted the analytics.js tracking script into my code, and now I am trying to get user data such as medium, source, etc. using javascript and putting them into variables. Is there a way I can do this using Client Id?

I assume you mean getting the data in realtime for use in your website. That is not possible.
Client ID is not exposed in the interface by default, you'd need to use a custom dimension.
There is a processing delay, report data may only be reliable the next day.
While there is the (less reliable) data from the real time API (which at least contains medium and source information) it does not support custom dimension, so you could not use the client id as query key.
Also to retrieve data from the API you need to be authenticated, which the current users of your webpage is not. So you would need to set up some kind of serverside proxy that handles authentication for you.
Also there are API limits determining how many requests you can make in a given time frame. Even a small site would exhaust those requests pretty quickly.
So while in theory this sounds doable it is not actually feasible for any real-life purpose.

Restrict the registration for a machine C#

I have a web application that has form based authentication.
the application has registration functionality also. Since last few weeks, i have observed that some users with specific domain is making fake entries into the website and getting the benefits as We do not have any approval workflow.
this user either do it manually or run some script. We thought that we can restrict the registration process as per IP based, however this is not possible to get the visitor exact IP address using C# (please correct if i am wrong).
Can we do it using some other techniques. our requirement is - single registration from a machine per 2 days.

unfortunately I would call this mission impossible.
Idea 1: IP address. The user can use a proxy to register multiple accounts depending on how many proxy he can find (there are a bunch on the internet for free)
OR they could just fake the ip package by putting a random ip in the header. Since all they need is to register so it doesn't matter if the confirmation message was sent to another random guy
Idea 2: one registration per machine. I could fake as many machines as I want with virtual machine and you will have no way to tell from http request.
Alternatively I could just fake all the information with raw http request and I can do that with a script with no issue.
And from what I know you don't have the system right to read hardware id from js (correct me if im wrong)
No method is guarantee to restrict 2 registration per day but IP based method should work against most normal users. Do keep in mind that everyone using the same router could have the same IP (example school, public wifi in apartment)
You could find out the user's IP address within HttpContext object

Whatever your restriction would be - it will be based on the data the browser sends (as long you restrict a specific computer).
Your main desire is to create a "footprint" on that machine in order to use it later - per request.
Whatever your manipulation would be, you should also obfuscate your JS code.
for example, on pageload code you can request for httpheaders dedicated to that machine and save them in cache, then you generate a guid for the client which it suppose to use in order to register.
another option is to use AES to encrypt the data before sending it "on the wire", that way you won't be able to manipulate it.
the most important thing is that once you "drop" a js code on the client he can do whatever he wants, the question is how hard it would be.
**edit:
a more secured way but more complicated that i have once used is creating a sync-key.
an async ajax call to the server requesting an encryption key.
the server call will save the new guid-key in memory and will generate a new one for each request.
you can use this idea to keep track of user debug and browser behavior.
as debuging will hold the code from running the sync key will be change and you can "catch" him.

Neither cookies nor IP can protect against fake entries.
You should look at it from another side. You get unwanted entries and you don't know if it's an automated bot, or spammer, or someone who just doesn't care about your data. Instead of banning entries you should think how to validate them. For example, if you get "aaaaa" as a name and "bbbbb" as an email address - add, at least, regexp validation on client and server side to ensure you get data in a required format. Next level would be to verify the email address by querying the mail server or sending validation email. This will not only help to stop spammers, but also people who doesn't care. If you think it's an automated bot - add a captcha. In case of emergency - ban IP in the web.config (See ASP.Net How to limit access to a particular IP address to a particular page through web.config file (.htaccess similar)?)

Client side to server side google analytics MP client ID

I am trying to send transaction data to UA from a webshop which is only creating orders once it has received a "push" from a payment processing API. A success page is displayed to the customer independently from the order being created, meaning the tracking script (UA via GTM with data layer) does not have access to the order data.
This gives me the headache of trying to track transactions made through the webshop server side, instead of client side. Yet I still want to tie the transaction to the unique visitor ID who made the purchase, not just a random Client ID each time.
My site is using analyics.js (UA profile). Therefore I thought somewhere a client ID would be stored as a cookie, and I do see a _ga cookie there which I believe is the client ID, which looks like this:
GA1.2.1586737968.1429871710
The documentation for getting cookie and user identification states the following:
You should not directly access the cookie analytics.js sets, as the cookie format might change in the future. Instead, developers should use the readyCallback to wait until analytics.js is loaded, and then get the clientId value stored on the tracker.
... which is not helpful to me, as I have to do this server side. But anyway, this client ID does not even fit the description of what a client ID looks like, although it does appear to match a legacy format. Sort of.
Couple of questions then:
Is it just those last two numbers 1586737968.1429871710 that I need to be parsing from the _ga cookie and sending as a client ID? Or is the whole thing ok?
Are there any scripts/libraries that will do this for me so I don't have have to worry about Google suddenly giving new visitors the client ID based on the new UUID v4 format?
Does this approach have any obvious flaws?

Answers:
Yes the cid value should just be the last 2 numbers as you rightly point out. (this is experience from client setups that already successfully use Measurement Protocol on an ongoing basis)
Nope, not as far as I am aware, best to do it yourself. It will only be a few lines of code to detect what format you're seeing in the cookie and what, therefore you need to send through.
not really. It is a common enough scenario.

Cross-domain conversion tracking - Custom vs GA?

Say I'm starting a site, refer.com, where I post items on an 'affiliation' basis. When users click on my links, they're directed to the site shop.com. If the user I redirect to shop.com makes a purchase, I need that conversion tracked.
I see two possibilities:
Creating a custom tracking library (probably JavaScript) where I
request URLs from refer.com to transfer information from shop.com. I guess PHP would work too, but reduces compatibility with clients.
I use Google Analytics cross-domain tracking to do this. I don't
want the refer.com GA account to interfere with the shop.com GA account, but as I understand it you can use several accounts on the
same page, giving them different identifiers.
I feel like I'm stuck with a narrow set of possibilities. Do I do both? Neither? I need it to be as easy to implement as possible for the client, while also providing relatively bullet proof tracking. What's the standard today? Affiliation services are everywhere, and this type of cross-domain tracking has to be a very used technique. Is there another preferred method of achieving this that I'm not aware of?
This question might seem highly theoretical. While that may be true, answers with code are highly appreciated too.

I have a way for this to work but it requires both your domains to have the Universal Analytics code installed. This will not work with the older GA code
https://support.google.com/analytics/answer/1032400?hl=en
You can install multiple instances of the Google Analytics tracking code on your web pages to send data to multiple properties in your account.
You can, for example, install multiple instances of the Universal Analytics tracking code (analytics.js) on your web pages but only one instance of the Classic Analytics code (ga.js).
So (provided they have your GA code installed) when you refer to shop.com what you should do is this
Parse your GA cookie. You can get to it by $_COOKIE['_ga']. The cookie holds a string that has four parts, broken up by periods. (i.e. GA1.3.367110421.1357220305). You want those last 2 numbers (in this example 367110421.1357220305)
Pass the parsed cookie data in your referral to shop.com
shop.com should store the parsed cookie in its session
Last but not least, when shop.com has your referral data it should load your GA code and set your sessions up like this
ga('create', 'UA-YOUR-GA-CODE', {'cookieDomain': 'shop.com', 'clientId': 'USERS-PARSED-SESSION'});
What this does is it passes your GA session to their domain. At this point, GA will keep their session going so you can track what happens on shop.com. Any conversion data they pass to their GA code should be passed to your GA as well.
Is it bulletproof? No. You have to trust shop.com to properly retain and show your referrred GA session ID. But I have to use this methodology to keep my sessions between my primary sites and the centralized checkout we use and it preserves my Adwords conversions, etc.

I feel like if you're looking for ease of use for the client, Google Analytics is a pretty solid option. It is a widely used tool, with lots of documentation and active forums for feedback. Also, from my research on the topicit seems that they've got this type of behaviour in mind already.
An alternate that comes to mind is that, when redirected from site A to site B, they should be forced to authenticate on site B. You could then setup an authentication form that is unique to this referral from site A, and will be filtered into your database separately from regular authentications on site B.

generate fingerprint of client using javascript

How can i generate unique fingerprint of each client?
I know must use navigator object but some properties like navigator.battery cannot use in this method.
// battery included and unique may change.
var uniqueHash = exampleHash(JSON.stringify(navigator));
How can i generate correct unique fingerprint for each user just using JavaScript and without cookie.
Cross platform and older browser also must be included.
I need list of cross browser supported by navigator.X
Note:
I don't want to generate random hash. i want to generate system base hash for each user and i dont wanna save on Cookie or Storage.

How can i generate unique fingerprint of each client?
Short answer is that you can't. It's impossible to do this for every client. You can get close using invasive profiling of the client, but you'll probably only get a unique identifier in around 90-95% of cases.
and i dont wanna save on Cookie or Storage.
Is there a reason you don't want to store data client side? If you told us what you were trying to achieve then maybe we could suggest a better way to solve the problem.

One route that may be worth looking into is using the Mozilla Persona API. It exposes a navigator.id property for consumption. Getting a unique id from a user is as simple as...
navigator.id.get(function(unique_id) {
alert("this is your unique id: " + unique_id);
})
This has the downside of requiring user authorization
Example: http://jsfiddle.net/aJsL9/1/

Simplest way to keep a session without using cookies is appending a unique hash (maybe a UUID or something similar) to the urls in the page as a get parameter:
/my/fancy/url
becomes
/my/fancy/url?HASHCODE
whenever the server receives a request, it capture the HASHCODE if present, otherwise it generates one, and then append it to all links on the served page.
Please bear in mind that the user can manipulate the HASHCODE and you should take that into account when engineering your application.
Anyway, notice that it's quite ugly in the fancy-url era. Also notice that user tracking is a delicate subject and you might incur into legal problems if you do not properly declare it in the TOS.
EDIT: you cannot track a person across multiple web sites without using cookies in any of their variants (flash, session storage, etc.) and a domain shared between sites. No way, you cannot set a variable or cookie from one domain and access it from another one in any decent browser, otherwise it would be a big security hole.
EDIT: Panopticlick cannot be used as a tracking method as you suggested, because it is based on statistical matching and it is also pretty bad at that (try browsing https://panopticlick.eff.org/ from outside the USA or with the just-released Chrome/Firefox update). It's a good proof concept, but nothing that you can use for this purpose. Also, you would need a whole lot of samples to get statistically relevant results.
EDIT: Browser fingerprint identifying power is weak: many browsers are autoupdating (like Chrome or Firefox) and official builts are very few (20? 40? Maybe a bit more if you count Linux distribution-compiled ones), so you will find a consistent portion of users with the same user agent. Add that there is a pletora of consumer PCs with similar configurations.