getting device token and device ID

Hi guys,

I’m working on a project that requires me to get Device ID and token (for push notifications)

both are going to be saved on server, Device ID is used for auto login (when user has logged in once and has their device ID recorded on the server already) only while token is kept for future usage by people managing the backend.

Anyhow, I’m looking through expo docs and found these:

Expo.Constants.installationId : An identifier that is unique to this particular device and installation of the Expo client.

Expo.Notifications.getExpoPushTokenAsync(): This token can be provided to the Expo notifications backend to send a push notification.

I just want to know if these are suitable for the above use cases?
Also, is the token returned can be used outside the expo push notification scope? i.e. the one we are planning to build ourselves on our server?

Thanks in advance :smiley:

Both work because they are unique.

But, IMHO, your auto-login feature should be implemented using local storage, not through device identifiers.

1 Like

thanks for the prompt reply! :smiley:
I’m not storing it locally, but I can see the problem with the mechanism, it’s not my design really I’m asked to copy an existing project into react native using exact same API because the previous programmer accidentally deleted his IOS native implementation lol

Are you suggesting that the mechanism is flawed because anyone can simply hack into user’s phone device info and use it to login? Or is there other reasons? I might wanna bring it up with my supervisors and see what they think.
Because at the end of the day this is just a simple remote attendance staff check in app that does not have any sensitive information passed through the device and API…

Both ID and token are installation-based, so if the user reinstalls the app, these identifiers are lost and, consequently, the user profile as well.

And the user may install your app on multiple devices (phone and tablet, for instance) - it should be only one user profile, consistent across all devices.

IMHO, it’s much simpler to use your own ID, provided by your own server/database, than to rely on third party temporary identifiers.

Absolutely, thanks for the input, totally agree with u.
they are aware of that problem with reinstallation and multiple devices but still decided to implement it that way for some reason…
maybe it’s because this system is not an integrated system yet and they decide to just limit access to ‘real’ data and handle everything on the backend instead. Also, since the app is about attendance based on location check-in, I think they just want to make sure that only the owner of the device can check-in instead of asking other people to “check-in on their behalf”.

Really good point u brought up tho. thanks again! :smiley:

1 Like

I’d like to have more details in the docs about the Expo push token if possible:

https:/ /docs.expo.io/versions/latest/guides/push-notifications.html

  • Is this token unique per device?
  • If the user uninstall and re-installs the app does the token change?
  • What if the user resets the device?

https://www.minimilitia.mobi/ https://www.applock.ooo/ https://www.7zip.vip/

To my understanding most push token libraries would reset the token upon reinstallation or at least once u have deleted ALL the apps from ONE developer and reinstall some of them back.
This behaviour should be expected since the push notif usually needs to know the relationship between app and device, hence it makes sense to generate the unique ID based on intallations.

and due to that fact, it implies that the answer to ur first question would be yes as well as it is unique per device per install.

if u mean factory reset the device and wipe everything then the app should also generate new token upon reinstallation.

I believe that this info should be uniform across all lib when we’re talking about push tokens. Let me know if u find any of my info is misleading, I’m learning about it as well for my current project. :smile:

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.