I want to store data on the server and keep it segmented for each phone.
How do I get a device's UID number?
Per Mozilla's Device Model Inclusion Requirements, device makers and operators are strongly discouraged from adding a device identifier to the Firefox OS User Agent.
You should generate your own UID for each device that installs and runs your app, store it on your server and locally with either the Device Storage API (for privileged or certified app) or Web Storage (for un-privileged, un-certified app), and use your UID to segment and synchronize per-device data on your server.
As per this thread, there does not seem to be an API for getting the Device ID. I am not qualified enough to state if this still holds true.
Firefox OS also provides a list of Device Settings for privileged Apps but it looks like Device Id is not one of them. Take a look at this Settings list.
It's not meant to be used this way but you can use the window.location.host when your app is running to differentiate phones. The URL is a GUID that will be generated per app install, so it's different on different phones.
Since it seems to be impossible to get UID of device with current API, you could create one yourself. Just generate unique value on the server, pass it to the client app and store it using Storage API. Then use it each time you need this UID. This way you can also implement your own security policy for preventing "stealing" UID by other clients (you can control the length of the UID, change it from time to time etc).
Related
Basically, i'm trying to figure out if you can add a software to run alongside an already installed POSs, that can also access the barcode scanner?
Does it depend on whom the POSs has been installed with?
Please help!
I'm pretty new in this area, but I know that UPOS has the concept of Sharable Devices, multiple apps can use the device in this case.
Some devices are sharable devices. An example is the keylock. A sharable device allows multiple Control instances to call its methods and access its properties. Also, it may deliver its events to multiple Controls. A sharable device may still limit access to some methods or properties to the Control that has claimed it, or it may deliver some events only to the Control that has claimed it.
https://www.omg.org/retail/unified-pos.htm
#Rachel McConnell,
It is certainly possible for two applications to use the barcode scanner if neither application holds an exclusive claim on the device when it is not actively using the hardware, however many POS applications assume they are the only application using the hardware.
If both applications are using Windows.Devices.PointofService, there is a negotiation process built into the platform that requires the application with an active claim to respond with a retain() to keep the claim if a second application requests a claim. If the first application does not respond with a retain() in a matter of seconds, the claim is revoked and given to the second application. I do not believe other UnifiedPOS implementations provide similar capabilities.
For more information, see: https://learn.microsoft.com/en-us/windows/uwp/devices-sensors/pos-basics-claim
Hope this helps
Terry Warwick, Microsoft
I tried to generate code for a device changing the implementation type to SharedLibrary and renaming the Entry Point to Device_Name.so. I was able to generate and build, but in main.cpp it kept a main function not a make_component to be called by ComponentHost. the device constructors deals with arguments that ComponentHost doesn't, like the Device Manager IOR. I believe this functionality extension implies changing the source code of ComponenHost. Is it part of REDHAWK roadmap? any comments on how can I make it work?
So are you trying to use the shared process space within a node to communicate between devices and services? Because I don't believe that there is tooling specifically for this yet, but I think there is a way to do this. Just to be clear I haven't tried this, but based on the test used by the bulkio ports to determine local vs remote transport usage, I think this will work.
If you look at the persona pattern, you'll see that there is a Programmable Device which is responsible for loading Persona Devices. Most of the details for this aren't necessary for what you're trying to do, but the pattern should be helpful. To accomplish communication between Devices using shared memory, you could generate a Programmable device whose sole purpose is to forward parameters from the DeviceManager to the Personas. The Personas would then act as your normal Devices normally do, just launched in the same process space as one another.
The code generators for the Programmable and Persona Devices are not yet integrated into the IDE, so you'll have to create a new Device project in eclipse for each Device you want (so that you'll have the spd files). Be sure to add the appropriate AggregateDevice interface to your Devices. This let's the framework know that multiple devices can technically be considered one entity, but you can also individually communicate with each. Also make sure that the Programmable is an Executable Device, since it needs to launch the Persona Devices. Then, from the command line, you can run redhawk-codegen - - pgdevice </path/to/programmable/spd> to generate a Programmable Device, and redhawk-codegen - - persona </path/to/persona/spd> to generate your Persona Device(s).
Once all of this is done, you'll notice the main function for your Programmable launches the Device like you described in your question. However, the main function for the Personas has code to launch the Device as either a standalone Device or as simply an object in its own thread.
This should allow the bulkio ports of the Programmable and Personas to communicate with each other via shared memory. Obviously this will break down if you attempt to push data out of the process, at least until someone adds interprocess shared memory via something like shm. Not sure if that's on the road map, but it would certainly be neat.
Update: It appears that interprocess shared memory was added in RH 2.1.2, so you should be able to communicate between collocated Devices, Services, and Components using that mechanism. This renders the above unnecessary, but I'm going to leave it for earlier versions of RH.
Let me know if you have any questions!
As of RH 2.1.2, the default behavior for Devices/Services/Components whose user code uses redhawk::buffer for the data memory allocator and the stream API for interaction with the bulkio port is to use a shared memory transport between C++ entities that are running in different processes
I am working on a universal application, and I am trying to detect whether it runs on a desktop computer or on a real IoT device (Raspberry PI 2). Following the recommendation, I am trying to use API contract checks, however this returns true even on the desktop machine:
ApiInformation.IsApiContractPresent( "Windows.Devices.DevicesLowLevelContract", 1, 0 );
Obviously when I try to call GpioController.GetDefault(), it fails on the desktop, but strangely with a FileNotFoundException: "The specified module could not be found."
So what is the right way to detect a real device?
Thanks for your help,
György
Edit:
On some desktops GpioController.GetDefault() returns null, while on other machines it fails with FileNotFoundException.
Edit:
My goal is to ensure that I can safely call any GPIO or IoT Core specific APIs without using try-catch blocks everywhere to handle exceptions when running on a non-IoT device.
You can find the type of device your app is running on by
Windows.System.Profile.AnalyticsInfo.VersionInfo.DeviceFamily
Source:
https://msdn.microsoft.com/en-us/library/windows/apps/windows.system.profile.analyticsversioninfo.aspx
Microsoft does suggest to maximise your reach with universal apps by checking for capabilities instead of just checking the device family.
There's an article about all that here:
https://msdn.microsoft.com/en-us/library/windows/apps/dn894631.aspx
It depends on what aspect of a "real device" you want to check. Using API Contract information is not a good proxy, as you have found (although it should return null, not crash, on desktop -- that's a bug). Using AnalyticsInfo can be a reasonable proxy but you have to be careful about receiving new values over time, plus it actually identifies the OS type rather than the physical hardware. Enumerating hardware devices is the best way to detect hardware, but they can come and go dynamically as the user plugs and unplugs them.
What is it you are looking to do differently based on the answer?
I suspect we're all familiar with how facebook and google and the like detect if you're using a different device than usual, I was wondering what the most reliable way to do this is?
I'm talking about the old 'It looks like you're signing in from a different device', and then when you confirm etc, it usually sends you an email and asks whether you want to trust this device or not.
Obviously one could just set a cookie, one that maybe get's checked and logged each visit, but what about when the user signs out? Do we keep the cookie?
Is there any other reliable method to 'trust' a 'device' other than setting cookies? Or is this the best/most reliable way to do it?
The most reliable way to detect a device change is to create a fingerprint of the browser/device the browser is running on. This is a complex topic to get 100% right, and there are commercial offerings that are pretty darn good but not flawless. I worked at one of those companies several years ago.
There is now at least one open source fingerprinting project Client JS. I have not used it, but it seems to cover the bases.
Just setting a cookie is not very reliable because on average users clear cookies about every 30-45 days unless you use a network that attempts to re-set the cookie (paid services). Even those are not flawless.
Just using the IP address is useless. Some devices legitimately have many IPs in a short period of time (laptop at home, work and Starbucks or most any mobile device), while sometimes a single IP is shared by a large number of users (all the folks at Starbucks or behind a corporate proxy server).
UPDATE
Thoughts on your similar hash code.
It is a complex topic to get right. I had a small team for a few years. We got pretty darn good, but you can never be 100% accurate even when people are not intentionally trying to trick you.
If the CPU changes, it's probably a different device.
The same physical device can have many user agents. Each browser on the device has a different user agent, and privacy mode of browsers have different user agents with far less entropy.
Fonts doesn't change very quickly for a given physical device, though it's not a great source of entropy on mobile devices (few fonts installed, and typically all the same ones for a given type of device).
OS is generally stable, until it suddenly changes. Does it matter in your case if every device appears to be a new device when it updates to Windows 10?
Color depth will be pretty stable. If the user installs a new graphic card, this may change. Does that matter in your case?
If you can accept thinking some devices are new when in fact they are the same and vice-versa, this type of similarity hash may work for you. Note that you can never use this type of fingerprint to uniquely identify a device for a purpose that requires positive identification such as access to secure data. It's great for making probabilistic decisions such as serving an appropriate ad.
I'm an embedded engineer (not a network guru) building a piece of Linux-based equipment (a portable measurement instrument) that is normally not connected to the Internet, but we need to make it possible for the equipment to "call home" for support, including updates and troubleshooting, in a manner that compromises neither the product's security, nor the customer's network security nor our own company network.
The "call home" capability will be completely controlled by the user, perhaps by pressing a physical button to activate it, after the equipment has been connected to whatever network the customer chooses to use. For prototype and demonstrations systems, this network could be at someone's home or office or even via a phone connection (the equipment will contain only a wired Ethernet port, and the customer would need to provide a wired AP if WiFi access is desired).
Making the connection should require no per-call configuration at the user's end, nor within our box, so I'm thinking we can require the customer to provide DHCP, and not much else. We can also require the customer to first contact us before pressing the "call home" button, so we can have our support interface up only when needed.
When a unit does "call home", it merely makes a connection to a company system, doing nothing else until an engineer (well, me) directly connects to it. Other than the existence of the connection, we should get no (or minimal) information about the network the customer is using. So I'm thinking some kind of SSH connection, but that's as far as I have gotten.
If possible, it should "feel" as if I'm connecting locally, as if the unit were on my desk (perhaps with much more latency, loss, and minimal bandwidth).
But I have no idea whatsoever how to make an SSH connection (if that's the right tool to use for this) as two separate halves: The remote unit "calls" somewhere, presumably on one of our company systems, then that system notifies an engineer (me) that a "call home" has been initiated, then waits for the engineer to connect, forming the other half of the connection.
The connection need not identify the remote system (make, model, serial number, version, etc.): I'd do that manually after logging in securely.
If needed, I can create a new system on our end (Linux, BSD, Windows, whatever, physical or VM) that can be dedicated to just this function. I can get at least one static port mapped out to our corporate WAN, if needed (but something I'd prefer to avoid, if possible).
Ideally, I'd also like for there to be minimal information in the equipment itself, so that possession of the equipment by an adversary (or competitor) could not compromise customer or company networks, other units, nor the call-home technique itself. From what little I know, I'd guess a hostname or IP address, a port number, and a key would be needed, but less would be better!
I'd also like the system to require manual intervention at both ends, with minimal automation that can be buggy or be compromised. Once we implement and test the initial system, automation could be added as our experience with it, and confidence in it, grows.
That's about as far as my thinking has taken me. Beyond this, I'm pretty much clueless. Am I on the right track? What pieces am I missing? Is this already a popular thing to do, and I simply don't know what it is called? How simple and stupid can this capability be made for a couple of prototype systems?
EDIT: If it wasn't obvious already, please assume I'm a networking idiot who can be trusted only to follow an explicit recipe, and not much more. KISS applies!
Disclaimer: as long as no "real" answer is there I just provide my more or less theoretical thoughts with hope it helps.
Without reading in detail, I found http://www.vdomck.org/2005/11/reversing-ssh-connection.html to reverse a ssh-connection. If that is easy to follow (it should be easy, just ssh -R basically, see also http://www.brandonhutchinson.com/ssh_tunnelling.html) it means your remote device could connect to your network (and "Pete" is your Partner at the customer). The problem is that initiating a ssh-connection without user/password requires a authentication- private key on that device (so in non-friendly hands).
You could place a dumb ssh-server with no private data and no special access and even the password you could set just for that single connection (and tell your partner "Pete" via phone), let your phantasie play a bit to get a static half "ImGenious$%" and a dynamic half "1243" so you can give a short easy dynamic half over phone.
Then from that dumb ssh-server you can connect to your device as in the article.
I would suggest the call home functionality uses SSH to connect to your office. This requires your customer's network provides DHCP, Internet access and DNS capability. It also requires them to allow outbound connections on port 22. The latter is possibly an issue for some security minded customers who want to prevent unknown egress of data.
You will need a certificate for your SSH server so the certificate is valid for the domain name you choose. You will also need to make sure the SSH client on the server is configured to accept the signature of your server.
It sounds like the number of devices you will be maintaining is relatively low. For this reason, I would suggest generating unique public/private key pairs for each device. You can then load the public key into your server so logins are accepted via keys only.
If a device is compromised or stolen, you can delete the appropriate key from your server. The device will not be able to login again. The private key on the device only has value because you have decided to accept the associated public key on login. Remove this and it has no value. The added benefit is that you can identify a device by the key it has used to login (e.g. you can associate each key with a different user). You can then tie up the login with the information about the device/customer that you store on your systems.
If you use reverse SSH you can have the device connect in. Once you're ready, you can use the reverse part to connect through the tunnel that the device and your server have already setup to perform the maintenance.