When my server gets a request via webservice i want to send a pageview hit to my google analytics.
Measurement Protocol requires a Client ID, in this case i want to set the server as id as client.
Should i just fake data like &cid=1 or there is any other way?
The client id is there to aggregate interactions into sessions and users. If you have no need to separate visits into different users you can generate a static client id and use that - you then will have only a single user which makes the reports look a bit strange, but as far as technology goes there is nothing wrong with simply using an random integer (the recommended format is UUID, but that's just to avoid situations where different users get the same id. This does not seem to be an issue).
However if your webservice users send along a token that is unique per user I suggest you use that (or rather a hash value based on that). This will allow you, amongst other thing, to see how many different users use your webservice.
Related
My question is more of a conceptual one, but in my specific case I am using Google Analytics 4. If the question is unclear, here it is in scenario form: Some guy visits my site x.com after a google search. He closes the tab, does another google search, and arrives at my other site y.com. How do I know it's the same person? I don't think there's anything I can do with User ID's in this situation. How would I solve this?
This isn't without fault, but if you are implementing it via Google Tag Manager, you have more control over the data being sent and on top of that, if you are transporting the data via Google Tag Manager server side container.
You would use a single server (but possibly different containers) or use BigQuery and either use the templateDataStorage API call or the BigQuery API call.
Essentially, the first time you see a google cid or an IP address or combination of user agent and ip address you would store it in the server or in a BigQuery table as a key and create a random associated value next to it.
At each time, across all your sites, you would check to see if the IP address or CID or combination of user agent and ip exists in the server or in the BigQuery table, then output the random value as a custom dimension and if not, it will create one.
Actually you probably wouldn't.
Presumably you could try fingerprinting, but depending on your legislation that might not be quite legal, and it tends to work a lot better in a lab than in real life. Also browsers start to implement anti-fingerprinting measures such as trimming the user agent, and denying access to browser properties such as installed plugins.
I have heard of experimental approaches to recongnize users via usage patterns - e.g. how do they move their mouse etc. I am not aware of any actual product that uses this, and I am not convinced it is a useful (or even legal) approach.
But in general, when it comes to cross-domain detection for unrelated visits (moving from domain to domain works via link decorators, and even that is affected by browser protections) you have the combined power of browser vendor against you, who try to make this harder (either for genuine concerns about privacy, or to establish themselves as the single gatekeeper for user identity. E.g. Google has a huge user base that is almost constantly logged in to Google accounts or Android smartphones, which helps with identifying users all over the web).
I'm trying to get started implementing Web Push in one of my apps. In the examples I have found, the client's endpoint URL is generally stored in memory with a comment saying something like:
In production you would store this in your database...
Since only registered users of my app can/will get push notifications, my plan was to store the endpoint URL in the user's meta data in my database. So far, so good.
The problem comes when I want to allow the same user to receive notifications on multiple devices. In theory, I will just add a new endpoint to the database for each device the user subscribes with. However, in testing I have noticed that endpoints change with each subscription/unsubscription on the same device. So, if a user subscribes/unsubscribes several times in a row on the same device, I wind up with several endpoints saved for that user (all but one of which are bad).
From what I have read, there is no reliable way to be notified when a user unsubscribes or an endpoint is otherwise invalidated. So, how can I tell if I should remove an old endpoint before adding a new one?
What's to stop a user from effectively mounting a denial of service attack by filling my db with endpoints through repeated subscription/unsubscription?
That's more meant as a joke (I can obvioulsy limit the total endpoints for a given user), but the problem I see is that when it comes time to send a notification, I will blast notification services with hundreds of notifications for invalid endpoints.
I want the subscribe logic on my server to be:
Check if we already have an endpoint saved for this user/device combo
If not add it, if yes, update it
The problem is that I can't figure out how to reliably do #1.
I will just add a new endpoint to the database for each device the user subscribes with
The best approach is to have a table like this:
endpoint | user_id
add an unique constraint (or a primary key) on the endpoint: you don't want to associate the same browser to multiple users, because it's a mess (if an endpoint is already present but it has a different user_id, just update the user_id associated to it)
user_id is a foreign key that points to your users table
if a user subscribes/unsubscribes several times in a row on the same device, I wind up with several endpoints saved for that user (all but one of which are bad).
Yes, unfortunately the push API has a wild unsubscription mechanism and you have to deal with it.
The endpoints can expire or can be invalid (or even malicious, like android.chromlum.info). You need to detect failures (using the HTTP status code, timeouts, etc.) when you try to send the push message from your application server. Then, for some kind of failures (permanent failures, like expiration) you need to delete the endpoint.
What's to stop a user from effectively mounting a denial of service attack by filling my db with endpoints through repeated subscription/unsubscription?
As I described above, you need to properly delete the invalid endpoints, once you realize that they are expired or invalid. Basically they will produce at most one invalid request. Moreover, if you have high throughput, it takes only a few seconds for your server to make requests for thousands of endpoints.
My suggestions are based on a lot of experiments and thinking done when I was developing Pushpad.
Another way is to have a keep alive field on you server and have your service worker update it whenever it receives a push notification. Then regularly purge endpoints which haven't been responded to recently.
I just finished one SignalR sample, the well-known Chat sample.
This sample just broadcast a chat message from one client to all the clients. What if we want to send message to only a specific client?
(I guess there should be some ID to identify each client. These IDs should be stored on server when clients subscribe to the server. And server can choose which ID to push message to. )
You have different way to map your user with a connection. You can compare the different ways in this tutorial depending on your requirements.
Another solution is to define 1 group per userId and notify the group when you want to notify a user (link). Be careful, groups are not secured.
Like Daniel describes you can use a group or use the hubcontext to get the context for a specific connection using the connection Id.
var client = context.Clients.Client(connectionId);
There are also several libraries that abstract SignalR, some of these comes with their own way of calling specific users.
I have made a library like this which is based on the Event aggregation pattern. It comes with a API to let you create code that determines which clients should receive a specific event
https://github.com/AndersMalmgren/SignalR.EventAggregatorProxy/wiki/Implement-constraint-handlers
Here is also a blog post I made showing how you can achieve declarative role authorization with my library, maybe it can give you some ideas.
http://andersmalmgren.com/2014/06/12/client-server-event-aggregation-with-role-authorization/
I have an MVC application that I would like to add some custom stats to. For some of the stats, it would be nice to have a unique identifier for a device.
For example, if I have a unique id for a RSS subscriber, I can monitor the active number of RSS subscribers.
I was wondering if anyone knew of anything in the web request that could be used as an ID other than the IP (which can obviously change). Something like a device ID or something?
Here are some approaches to consider.
HTTP Headers
There are a few HTTP Headers you can look at that can help you identify a unique user or device - some would refer to the sim card, some refer to the device.
Here is a list that I derived from the headers that Google Adsense Mobile uses to help track their advertising:
x-dcmguid
x-up-subno
x-jphone-uid
x-em-uid
These are probably some very popular one's, but there would be more vendor/device specific headers that are popular. You could start gathering all the headers your site receives and count how many of each you receive and start building up your own database of common headers.
Some other approaches
Cookies
Cookies is something that can be set on the requesting agent (browser for example) and returned when the agent visits again. For a list of methods, check out Ever Cookie - the virtually permanent cookie - it works by using one of the following methods of which at least one will work:
- Standard HTTP Cookies
- Local Shared Objects (Flash Cookies)
- Silverlight Isolated Storage
- Storing cookies in RGB values of auto-generated, force-cached
PNGs using HTML5 Canvas tag to read pixels (cookies) back out
- Storing cookies in Web History
- Storing cookies in HTTP ETags
- Storing cookies in Web cache
- window.name caching
- Internet Explorer userData storage
- HTML5 Session Storage
- HTML5 Local Storage
- HTML5 Global Storage
- HTML5 Database Storage via SQLite
Combinations
It's also possible to come up with your own scheme, e.g. take the user-agent header, some other headers like accept, x-fowarded-for and the ip make a unique hash value of out them to more accurately determine the uniqueness of the agent.
There are many different mobile headers as seen here. I also hit a page of mine and store mobile headers from various devices for my own purposes here http://wap.defza.com/ua/ua.txt (also ua1.txt, ua2.txt etc)
The short answer is their isn't any (and with good reason given privacy concerns). The more helpful answer would be that this is something you would normally do using cookies. You set a cookie and then check that to identify the specific browser making the request.
Of course, this is by no means fool-proof as users can reject cookies, delete them and they can use many different browsers (each of which will have a different cookie). If you are being devious (and I wouldn't recommend this) you could use a Local Shared Object (Flash Cookie) as this is less likely to be removed. At the end of the day, though, if someone doesn't want to be tracked you can't force them to be.
Generally, though, if you want analytics and tracking then consider using a 3rd party solution like Google Analytics. This will give you very detailed data (albeit still relying on cookies and javascript) about your visitors and their browsing habits.
other than the IP
If your site doesn't require any sort of authentication in order to serve this content, the IP address is the only thing you could get to identify clients, and even this might not be unique, for example you could have two clients behind the same proxy => no way of distinguishing those requests in this case. Another possibility is to use cookies, but that sort of falls in the first category => authentication.
There is no identifier that's provided by a browser, privacy concerns make it very unlikely that any vendor would ever implement that, now at least.
The only option you have is some form of cookie.
For RSS feeds, you could conceivably embed a random unique ID in the feed URL every time its rendered, so you'd know when the person that retrieved that URL downloaded your feed. However, if the user shared that URL with others you'd have no real way of knowing.
I have a web application, where users will see notifications for their new messages, I want to push the notifications to the users who are already logged in.
I have seen that I can do it using Server Push of PokeIn, I have tried and understood the simple application using it, but I am not getting the ClientID thing.
The ClientId it saves in "OnClientConnected" is a simple integer, so how does it recognizes clients and calls functions on them ?
Also, it is written that it uses a hybrid long polling approach, can somebody please explain me what is this?
I will not be able to implement without having sufficient knowledge of it.
Does saving the ClientID in the database for logged in user and then pushing data using this will do ?
UPDATE:
Even from requests within the same
browser window or tab, the ClientId
received every time on every request
is different, so I had to include the
Handler in my master page and on every
request, I had to map the ClientId
received to the Logged In user, so
that I can send messages to him.
Can't I just map the (ClientId to
LoggedIn UserId) only once on LogIn
and then use that same ClientId to
send him messages ?
ClientID represents the identification key of the specific client view of your application and subject to change on each time.
It helps you to manage and target specific views by keys. On the other hand, you can still use ASP.NET session ids with PokeIn client ids.
The only difference is, if any user opens your application on the different tabs of same browser, each tab will have a unique client id. Actually, this is a great
functionality you may need. On the other hand, PokeIn also notifies you when a client is disconnected (almost instantly)..
You may reach session id by the client id;
CometWorker.GetSessionId(string ClientId)
or client ids for a session id by;
CometWorker.GetClientIdsBySessionId(string sessionId)
Additionally, if you don't want to use client id system (which is very useful), you may choose the "Joint" option. It helps you the send and receive messages from
the client with the name you have defined. (There is a sample for the "Joint" feature in here)
Because PokeIn provides various connection options, you don't have to think about the approach behind it when you work with PokeIn. It simply provides benefits
from the various solutions. More information can be accessible from : "FAQ" and "Advanced Tutorial" (http://www.pokein.com/Help/AdvancedTutorial.aspx)
At last, you don't have to save PokeIn client id to the database. PokeIn manages your server side objects per each client efficiently.
I suggest you to check the samples and tutorials.
As an answer for your update, you are free to use Joint feature of PokeIn when you need shared server side instances for the clients or consistent naming for the clients.