Hi Dilshan
Actually there is another type representing device identification. For iOS > its universal device identifier (UDID) and for Android its the device id > which is either IMEI (for GSM) or MEID (for CDMA phones). So it has to come > as the 4th point. > We do not need a 4th point for this. The second point I mentioned (in the previous mail) that is "unique id generated by the device" is the UDID for iOS and for Android it can be IMEI or MEID. In the server side, this is stored as *UDID* as it is uniquely for the device and the value is sent by the device. 1) Generated by EMM server. > These are unique UUIDs you need to crate at EMM server end. This is simply > a challenge which needs to identify the associated payloads in the > enrollment flow. Right now we use user UID to deal with this. I think this > has to be refactored and generate a UUID on request basis and store it in a > temp table to be looked up with device type and user UID. The way proposed > will be better since in the current implementation this has an issue if 2 > devices enroll at the same time with the same username (but its very > unlikely). > Yes, currently the UserID is used as the challenge token to associated with the payload. This is the unique field that I mentioned that is generated by the EMM server. In the new version, we are generating a UUID and storing it in the device table as *challenge_token*. Currently we are using this only for iOS but we might need this when we add new devices like windows phone, etc... What I have proposed was that we generate a UUID for Android devices as well and Android devices use this to uniquely identify itself with the EMM server instead of using the GCM registration id. > 3) Generated by the GCM / APNS > This is actually specific to OS. For GCM you have the registration id. For > iOS you have 3 tokens in MDM flow. Those are MDM token, magic token and > unnlock token. Also for normal push you will be given a push token. Right > now 3 MDM tokens are stored in the same field as a json string. Normal push > token is saved in reg id field. This needs to be refactored. How do you > deal with above 5 types of tokens in your new proposed way? > For Android, it will have only the GCM registration id and for iOS this field will have the MDM token, magic token, unlock token and the normal push token. This is used by the server to sent message to the GCM / APNS. These are actually generated by a 3rd party for uniquely identifying the device. I am proposing that we store all these value in a json format in a new field called *token* in the devices table. The device should not use these values to communicate with the EMM server. Regards, Nira On Mon, May 5, 2014 at 12:46 PM, Dilshan Edirisuriya <[email protected]>wrote: > Hi Niranjan, > > Actually there is another type representing device identification. For iOS > its universal device identifier (UDID) and for Android its the device id > which is either IMEI (for GSM) or MEID (for CDMA phones). So it has to come > as the 4th point. > > Please find the comments on above points. > > 1) Generated by EMM server. > > These are unique UUIDs you need to crate at EMM server end. This is simply > a challenge which needs to identify the associated payloads in the > enrollment flow. Right now we use user UID to deal with this. I think this > has to be refactored and generate a UUID on request basis and store it in a > temp table to be looked up with device type and user UID. The way proposed > will be better since in the current implementation this has an issue if 2 > devices enroll at the same time with the same username (but its very > unlikely). > > 3) Generated by the GCM / APNS > > This is actually specific to OS. For GCM you have the registration id. For > iOS you have 3 tokens in MDM flow. Those are MDM token, magic token and > unnlock token. Also for normal push you will be given a push token. Right > now 3 MDM tokens are stored in the same field as a json string. Normal push > token is saved in reg id field. This needs to be refactored. How do you > deal with above 5 types of tokens in your new proposed way? > > > Regards, > > Dilshan > > > > > On Mon, May 5, 2014 at 10:29 AM, Niranjan Karunanandham <[email protected] > > wrote: > >> Hi all, >> >> When refracting the code that there are three types of unique fields >> [1<https://github.com/wso2-dev/product-emm/commit/8396f05c8f82587f6e9eb1c6382138d6cf065381>], >> namely >> >> 1. Generated by EMM server >> 2. Generated by the Device >> 3. Generated by the GCM / APNS >> >> The token generated by the GCM / APNS should not be used for >> communication between the device and the EMM server because it is generated >> by third party. We need to use either the generated by EMM server or by >> the device. Currently in android un-registration, we are using the GCM >> registration ID to communicate. This needs to be changed. >> >> >> [1] - >> https://github.com/wso2-dev/product-emm/commit/8396f05c8f82587f6e9eb1c6382138d6cf065381 >> >> >> Regards, >> Nira >> >> -- >> >> *Niranjan Karunanandham* >> Senior Software Engineer - WSO2 Inc. >> WSO2 Inc.: http://www.wso2.com >> M: +94 777 749 661 <http:///> >> > > > > -- > Dilshan Edirisuriya > > Senior Software Engineer - WSO2 > Mob: + 94 777878905 > http://wso2.com/ > -- *Niranjan Karunanandham* Senior Software Engineer - WSO2 Inc. WSO2 Inc.: http://www.wso2.com M: +94 777 749 661 <http:///>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
