Since version 6.2 the device ID is deprecated. Is there another way to uniquely identify the client that is using my service? It doesn't really matter what kind of identifier. It just has to be unique for the client.
The only way to have a completely 100% consistent token for the system
as a whole would be to use DeviceLink authentication rather than sessionID authentication.
A deviceID will still always been returned with a response (this will
not change even though it is now “deprecated”). The caveat with the
deviceID is that this ID is generated based on the device with the
lowest serial number in a user’s household. As a result, if a user adds a
player that is older than all of their current players to their household, the
deviceID may change. However, if you are simply looking for a generic ID
this may still be the least complicated solution. All that would happen if the device ID changed would be a refresh of the user’s sessionID (if this is the authentication method being used), which could happen in the background with no
user interaction.
Sonos is also now offering a new capability flag with our latest release called “Include Zone Player Ids in Credentials header.” This would enable unique, static Ids to be returned for each zone player in a user’s household. This is the most reliable way to know you are getting an ID that will always be consistent within a household.
Related
I want to make a service that allows to bind private user's channels to a user's account.
The user opens a private channel with my node. But I don't know which user exactly.
To identify the channel, I plan to ask the BOLT11 request from user, with a unique identifier in the description, like an SMS code.
BOLT11 specifies the target address of the payment. I will find a route for this request and thus determine the user's channel.
Is such a scheme safe? Can a fraudster create a BOLT11 request for a channel that does not belong to him? Сan you suggest a better identification scheme?
Can a fraudster create a BOLT11 request for a channel that does not belong to him?
Bolt 11 states:
The recovery ID allows public-key recovery, so the identity of the payee node can be implied
I'm not sure how every implementation matches the specification here. I would assume that all of them perform signature verification, but they might not expose public-key recovery functionality. Your idea of finding a path without actually paying the invoice might work.
However it seems that what you need is actually to identify an existing private channel between your node and the user's. Private channels should be included as routing hints in the invoice, so it might even be easier to get it from there by just decoding the invoice.
An alternative option would be to ask the user to pay an invoice generated by your node, a msat would be enough. For sure she won't be able to craft a payment with a node she doesn't control.
The safest way would be if the user signes a message with one of the keys that he uses to sign commitment transactions. This would certainly bind his identity to the channel. However current implementations don't offer that api. But that does not mean that this would not be possible
I am creating a unity game where users can post their high scores after a successful match, my problem is that some users can post directly to the api, without playing a match. How do i curb such an issue. I have read some articles about using native mobile encryption to help. but i do not know how this can be applied to Unity since it is a layer above native. what techniques can i use ?
Encryption will only solve a part of the problem, when users send fake requests to your API. But if I were you, I would perform server-side validation based on the parameters sent by the client.
How: Send one request to the server when a match starts, along with necessary details such as the user name. When the match is finished, send another request to the server, check the score against some heuristics based on how long the match took, and whether the score makes sense given the user's specific setup (levels and equipment, etc.) if you keep that information on the server.
Why: There's no reliable way to control what the user does on his client: he can change the values in memory, send forged requests, and so on. If the user meddles with the memory to give himself "100x damage dealt", your client may not know, and will dutifully record the (now tampered) score and send it to the web API. Encryption will not help you here since the request is just like the real thing except it contained a fake score to start with.
The id I get from app.getUser() from the actions-on-google-nodejs app looks entirely different from the id I get from Oauth.
app.getUser() in Google Assistant
{ userId: 'KMdEs***szG-ZRQl***cU',
user_id: 'KMdEs***szG-ZRQl***cU',
userName:
{
[...]
The same id is returned with and without the app.SupportedPermissions.NAME permission.
googleUser.getBasicProfile().getId() in Google OAuth
11348***63489
Is there any way to match these users up? It's the same Google Project in the developer console, so I assume that even if Google would generate unique ID's per project it should be the same, however in this case it looks like I am getting entirely different types of id's.
They are different types of IDs.
The ID returned from app.getUser() is meant as an anonymous project-unique identifier that can be used in some of the same ways a web cookie is used. It can not be identified against a specific account - but it will be consistent across all sessions (unless reset by the user). The profile information you can get with it (their name) is also considered non-identifying. Both are intended to be used to make a more friendly interface, rather than as a firm identifier. Users are able to reset their Google Home devices, for example, and this may reset this to a different ID.
The ID returned through OAuth, however, is meant to link them to a Google Account, with all the implications that brings, including associating them with a specific identity. This Account Linking is done separately, and does not directly give you the ID - instead it gives you an OAuth Access Token (which you can get through app.getUser().accessToken) which you can use to get their Google ID and other information that you may be scoped to get.
In theory, if you have Account Linking enabled, you could match the two up. In practicality, if you have Account Linking enabled, you wouldn't care about app.getUser().userId since you have the Access Token which will get you their Google ID. If you do not have Account Linking enabled - there is no way to match up the two and you should treat the userId as an anonymous (but consistent) user.
I have an app that using in some health caring center. When user login to system for the first time, my app will generate a UUID for current device. This UUID will be store it in SSKeychain and insert into DB . Next time, when login app, UUID will be get from SSKeychain, and update the last time that user login to SSKeychain info on DB.
Depends on UUID of devices, i can manage the number of devices that a center has. However, when device is reset, UUID of device seems to be removed from SSKeychain. So that, when user login again, my app will recreate a new UUID. This UIID will be insert into DB, while the old UUID still be in DB. This leading the real number of device in every center is different with DB.
So, could you show me some ways that create a unique identifier for each device(iPad, iPhone) that can be maintained even device is reset, restore or something else.
Thanks for advance.
First of all, I do not think that it is possible to generate a unique device identifier from the device itself. In previous times this was possible – you could simply ask the system for such a UDID (UUID of the device) –, but Apple stopped that for data protection reasons.
To reset a device means that the device is reset afterwards. Being reset means that you cannot match the "old" device with a number of devices. The reset device does not match the old device as every other device wouldn't do. This is the sense of resetting.
So, what you have to do is to let the user pair the reset device with one of the devices in a list on your server.
I have built a social network/dating type application on the AppEngine and am currently in the process of adding a chat built on top of the Channel API. However, the problem that I have is that users may reload or navigate to new pages while the chat is going on (as they can in Facebook). This means that the server doesn't easily know if it should generate a new channel ID token for a given client, or if a given client has already been assigned a channel token.
It would be extremely useful if there were a way to check (server side) if a particular client already has a channel open. For example, if I assign a client "Jack" a channel ID of "Jack-Jan-21-2010", then I would like to be able to check on the server side if there is already a channel open associated with the ID "Jack-Jan-21-2010". This can be (sort of) tracked on the client side by watching for an onerror() and onclose() callback, but I can't see anything server-side that allows me to just check if a channel associated with a given ID is already open.
Does anyone know an intelligent way to check (server side) if a channel has already been opened, while using the AppEngine Channel API?
Part 1: Solving your problem
See Part 2 below if you really need to track client connections, but I'm not sure from your question if what you're asking for will solve your problem.
Let me see if I can echo your problem back: you're writing a chat app, but it's for a site which isn't fully AJAX (in the way that, say, gmail is); the site contains page navigation where you may need to re-set up your channel after the user clicks on a link to another page. When the user navigates, the new page is rendered, and you want to avoid getting a new token at that point; you want to reuse the existing token and channel with the same client-id.
If that's correct, I have two alternate solutions, one easy but with not-great user experience, one trickier but with a much smoother end result.
Preserve the token in a cookie. When you re-render your page, just use the token from the cookie instead of calling channel.create_channel again. When the token expires you'll get an onerror callback just like if the user had stayed on the original page; at this point, call channel.create_channel again. The problem with this is that re-connection can be slow (up to 10 seconds or more in bad cases) because of the nature of Comet connections.
Wrap your entire site that's not chat-related in an iframe. Put your channel creation code and UI in the outer iframe. This way you don't have to re-connect every time the user navigates. This avoids the downtime on navigation. Note that orkut uses this technique, with floating divs, as a small amount of Firebug investigation will reveal.
Part 2: Your feature request
If it turns out I'm misunderstanding and you really do need to track client connections:
There's not a built-in way to check if a client is connected to a channel identified by a client-id now.
However, I am working right now on adding "presence" (in the chat sense) so that your app can register to get a post when a client connects to or disconnects from a channel created with a given client id. You also might be able to "probe" presence, to query whether a given client id is connected or not (still working on the details of this part).
Note that this won't be token-based, but rather client-id based.
I don't have a definite release date for this yet but as I said I'm actively working on it right now.
In the meantime, you could use a heartbeat HTTP request from your client back to your app that says, "hey, I'm still here" every minute or so. You'll need to have some sort of task that runs every, say, 2 minutes and marks any clients that haven't checked in as inactive, and you'll need to store this data someplace.