Hi -
From what I’ve read in the forum and the SDK documentation/examples, it looks like I am supposed to dynamically create a unique registration code on my web server. Then once that code is entered on my site, I have to create a unique device token which will be stored in the Roku user’s registry. How do you create the device token? Is it just a random number that is x characters long or is it the device’s ESN encrypted? If its an encrypted code, how do you encrypt it?
Thanks
The device token can be anything you want it to be. You just need it to be unique and associate it with a user account on your site.
A simple guidgen or something similar would server that purpose just fine.
–Kevin
Or you don’t need a device token and simply query the server with the device serial number when the channel loads to get the current subscription status. - you want to do that regardless to see if the user cancelled or not.
We do not advise linking via serial number and will ask you to change it if detected when you publish your channel.
The problem we have with that is if the Roku is sold on eBay etc… It would still be associated with the previous owner’s account information on your website.
If you store a device token in the registry, a factory reset will delete all registries and therefore device tokens when a new user gets the box. The Roku box would no longer be associated with the previous owner’s account information.
It’s OK to have the SN identified on your website for identification purposes to the user, but it should not be used for authentication.
–Kevin
Good to know. Can you add that recommendation to the SDK publishing and linking pdf? If the ROKU is sold on ebay it will still be associated with the account anyway until the user does a factory reset or the previous owner cancels channels - so the end user will still have to do something. I guess I’m not seeing why it would be a problem to continue to bill the original owner for their subscriptions they agreed to pay for - for their own stupidity? 
I’m not worried about 10 boxes being used in different locations, as we don’t know if they took the box with them to a hotel. How would you be able to prevent instances like that? Checking the IP Address wouldn’t work for a hotel situation either unless you wanted to add a webcam or biometric info through the USB port?
Would it be acceptable to use the RegWrite function in generalutils.brs to save the serial number of the device to the roku registry for the channel after it has been successfully linked, and read it back from the registry with regread to send to the authentication server if it exists when the channel loads? That way it can still be checked to see if it’s there, indicating the device has been linked, it could also be cleared with a factory reset, and if it doesn’t exist then go through the link to new account process as normal? Technically that wouldn’t be sending the serial number of the device for authentication, but a copy of the serial number for the device.
One more thing. (Sorry) - ROKU controls the channels on the Roku Box Account. All Roku boxes on the same account show the same channels installed for that account. You can go through and remove channels from individual boxes on the same account and eventually they refresh themselves to all have the same stuff on each one - I’m not sure if this is caused by a reset of the box in question, or if it happens during an update to the system, or what, but I’ve seen it happen before. By ‘controls the channels’ what I mean is, roku tracks which channels the user has installed, makes sure they are patched to the latest version stored on ROKU’s servers for the channel store, basically maintains them, does billing for a few of them where required, and keeps them organized, possibly tracks their display order, etc etc.
The individual channels themselves have their own billing systems and authentication systems on their individual servers - except for the few channels which are billed by ROKU. So, it’s possible, without a factory reset, for someone to ‘borrow’ someone else’s paid subscriptions on a roku device and use it at an alternate location provided the registry key exists which is used for the authentication.
So, I guess my real underlying question is - you need to use the serial number as it is to link a box - I just do not see any way around that requirement - it is already unique. How would you go about checking for a factory reset by the end user - which clears all information used for authentication - to automatically unsubscribe them from whatever billing system you are using if that was the only device on their account without accessing the serial number? Could a factory reset be designed to send out a notification method to all the installed channels, and could such notification also be added to the channel removal code on the roku device so that when a channel is uninstalled, all recurring payments would know to stop? Does the ROKU billing service do that?
Us a variation of what you are proposing. Instead of saving the serial in the registry on first run and sending it on link/run to link a player to an account, generate a uuid and store that instead. You will have a way to uniquely link each player to the service, and on factory reset the link is correctly removed.
destruk, you’re way overthinking it. The idea is that you use the Serial Number to identify the device during registration, but actually register it with some unique identifier that you generate, then store that in the registry on the Roku. When the box is factory reset, that unique identifier gets wiped, thus breaking the link.
As for subscriptions being transferred when a box is sold, that’s the original owner’s responsibility. As a general rule, you should always factory reset a device (Roku or other) before selling it to someone else.
“destruk” wrote:
Good to know. Can you add that recommendation to the SDK publishing and linking pdf?
It is spelled out pretty clearly in the DeveloperGuide.pdf…
“DeveloperGuide.pdf” wrote:
When using rendezvous style registration and account linking, be sure to store the linking
information in the device registry and not on your servers. We require that users are able
to do a “Factory Reset” and be confident that no personally identifiable information is
associated with the device. This is not possible if you have saved permanent serial
number information on your servers.
Thanks for that - It would still be a good idea to include that information in the DeviceRegistrationAndLinking.pdf. That uses the serial number during the linking process, which RokuKevin said to not do. “We do not advise linking via serial number and will ask you to change it if detected when you publish your channel.” Linking can be done without using a serial number, it’s just more of a pain in the butt.
“destruk” wrote:
Thanks for that - It would still be a good idea to include that information in the DeviceRegistrationAndLinking.pdf. That uses the serial number during the linking process, which RokuKevin said to not do. “We do not advise linking via serial number and will ask you to change it if detected when you publish your channel.” Linking can be done without using a serial number, it’s just more of a pain in the butt.
He’s saying not to use the serial number as the actual link. You can use it to identify for linking. In fact, the example in the DeviceRegistrationAndLinking.pdf actually uses it, but it’s used to generate a separate unique identifier for the actual link that gets stored on the box and your server.
Note in the below example XML, the “deviceID”/serial number is sent in with the request, but a new “deviceToken” is generated and returned. That “deviceToken” is what should be used for future authentication/identification with the server.
Request
Response
ok, you’re right. As long as the same packaging key is used for all channels then I can share the registry token between them, so that will work just as well as a serial number would have.
I truly apologize for my behavior here. I understand why they want it done this way, and it’s not difficult to change.
I do have another question though - how can I prevent the screensaver from activating during the linking process? I left a roku on the link screen last night, all night, and noticed a logged request and registration code from it on the server today so I deleted the record. 30 seconds later the record reappeared in the table - so I checked and the screensaver was active on the box. I was under the impression if the screensaver turned on, processing of the channel code would be paused, so how can I prevent execution when the screensaver is active?
“destruk” wrote:
I truly apologize for my behavior here. I understand why they want it done this way, and it’s not difficult to change.
I do have another question though - how can I prevent the screensaver from activating during the linking process? I left a roku on the link screen last night, all night, and noticed a logged request and registration code from it on the server today so I deleted the record. 30 seconds later the record reappeared in the table - so I checked and the screensaver was active on the box. I was under the impression if the screensaver turned on, processing of the channel code would be paused, so how can I prevent execution when the screensaver is active?
The way I think most people deal with determining when the screen save is active is including a custom screen saver with the app, and writing/updating a file in tmp:/ when it starts. The main program can check for the existence and content (to make sure it’s recent) of this to determine whether the screensaver is running. I haven’t done much with this, but I’m pretty sure TheEndless and renojim have used this method.
If you really just want to stop something from happening in the main code after a set period (and it doesn’t really matter whether the screensaver is running, per-se), create an roTimespan object and update it on every msg (or every msg that entails user input), and if you’ve been idle too long, don’t do the stuff you don’t feel like…
Do you think they’ll allow you to just ignore the screensaver timeout for a channel? If the videoplayer is doing something then it never turns on the screensaver.
“destruk” wrote:
Do you think they’ll allow you to just ignore the screensaver timeout for a channel? If the videoplayer is doing something then it never turns on the screensaver.
I doubt it, and as a user I wouldn’t want them to allow it. On display devices that can have burn in, I would rather not allow a poorly coded app to ruin my hardware. At least requiring a customer screen saver implies the coder has to actively try to replace the existing behavior, and hopefully pay attention to the results. It’s not that hard to implement a blank black screen, which I would consider the bare minimum.
If you were linking the roku to an account and the end user got sidetracked, allowing a screensaver to run all night isn’t much of a ‘solution’ as it continues to take server resources polling for the registration result. I’d rather have the program exit to the home screen than turn on any screensaver - so I’ll probably need to add a return code -1 to the registration routine when it has sat for 4.5 minutes since the minimum screensaver time is 5 minutes.
No need to exit, just back out to a failure screen, and offer them the chance to try again (generate new code, start over, etc.). That way they aren’t polling you all night AND when they do come back they are reminded they still need to link your channel.
That is good thinking. 
roAudioPlayer continues to work during the screensaver though, so I think it would be cute to have it say something every 5 minutes, like “ROKU needs you”
