We're changing the internal format of auth UIDs

[Kato Richardson]

Hi Folks! Hope you're all having a blast building apps on Firebase.

The format of the auth UIDs generated by Firebase will be changing on Monday, August 17th. We’ll be changing from an incremental integer to a UUID (universally unique identifier).

This will affect the email/password and anonymous providers on the 17th, and be extended to the OAuth providers (i.e. GitHub, Facebook, Twitter, and Google) at some undetermined time in the future. If you’re manipulating or parsing UIDs in any way, you’ll want to update your code and security rules before the 17th.

When new users get created after this date, you may notice that, instead of a string like <provider>:<number>, new accounts will have a UID assigned that looks more like f47ac10b-58cc-4372-a567-0e02b2c3d479. You should keep in mind that the contents of these strings are an implementation detail and not intended to be meaningful. They are only guaranteed to be unique and unchanging for a given user.

To reiterate, this will affect new UIDs created with createUser(), but will not affect any of your existing users’ UIDs.

Below is a quick checklist to ensure your code won't be affected by this change. If you have additional questions, reply here or reach out to sup...@firebase.com.

auth.uid.contains() or auth.uid.replace()

If you are checking auth.uid begins with, contains, or doing any sort of matching on the contents of this string, this will break. Particularly, if you are doing a replace on ‘:’, this will almost certainly break.

Alternatives: Use auth.provider to obtain the provider name. If you need to access the OAuth id (e.g. facebook ID) then you can programmatically store this in your data when a user authenticates (e.g. authData.facebook.id where authData is the return value from any authWith*() call).

auth.uid.length

The length of new UID strings may be radically different than existing UIDs created before this change. If you are checking to ensure the length is greater than zero, that should continue to work, or could simply be replaced by a boolean (e.g. “.read”: “auth.uid”).

auth.uid == x

If you are checking that the auth.uid matches another value stored in the data, this should continue to work perfectly. Existing users’ UIDs will not change and newly minted UIDs will have a different format, but still work with this approach.

How to test this change

If you want to test your existing code against the new format, this gist illustrates how to create a mock authentication token that will resemble the new UUID strings.

Have a great day,

Kato

[Piotr Kaminski]

Hi Kato,

Regarding *only* the OAuth providers part of this change:  Can you summarize the rationale for this decision?  Any chance that it'll be reversed?  If not, how much heads-up will we get before it's implemented?

Adjusting to this change would be inconvenient for me and the benefits aren't immediately clear.  I'd need to audit my code for UID construction/parsing, create a new lookup table (because Firebase lacks "deep" queries), and take a slight latency penalty on some functions.  Nothing insurmountable, of course, but I'd like to understand what I'm getting for this effort.  :)

Thanks,

    -- P.

--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-tal...@googlegroups.com.
To post to this group, send email to fireba...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/CADypTEaj-NDiV3_Zpr-9_9W_OfqboS1a%3D5G4wqCApf%2B_Hr87uw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--

  Piotr Kaminski <pi...@ideanest.com>

  "That bun is dirty.  Don't eat that bun."

[Kato Richardson]

Piotr,

There is no chance this will be reversed. The OAuth will not change immediately, and I'll be happy to work with you individually, but you should consider the 17th as a hard deadline. After this time, the format may change without notice at any time in the future; the format of this string is an implementation detail and should not be depended on, other than the promise that it will always being unique and consistent for a given user.

Some of the reasons for this change:

• We don't want people relying on the format and it was our mistake for making it simple to intuit that it was an incremental ID. We want to correct that before any others head down this path.
  
• UUID is more secure, since sequential numeric IDs can be guessed.
• UUID is more reliable, for the same reasons covered in our docs on arrays.
• Changing to a UUID allows us to further scale auth services, since an incremental ID requires all the servers to lock on that ID to increment it and create a new user
• It's going to allow us to add some new features to our auth services that have been hindered by the incremental ID and scaling limitations.

There may be additional justifications. These are the ones I've heard in passing conversation during feature discussions. If you have specific concerns, reach out to support; I'm happy to help you work through the changes.

Have a great day,

Kato

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/CANF_M5xi-c1p2yeKr%2BCvORMmhOMbL6ta%3Dp1qfRoNX9Szo4u7ww%40mail.gmail.com.

[Piotr Kaminski]

Thanks Kato, I'll get started on fixing my code.  I note, though, that all the benefits you bring up relate to Firebase-allocated sequential IDs, which are not an issue with OAuth IDs since those are created by the providers (and may or may not be sequential, but that's not Firebase's problem).  So, besides consistency, I still don't see a benefit to this change for OAuth providers...  Cheers,

    -- P.

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/CADypTEbCgwkYAM4_FJ%2BXE6ZiLoBDGVL-BtrqMo9NVGha_MGF1Q%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Zack Morris]

> On Aug 9, 2015, at 9:44 AM, Kato Richardson <wu...@firebase.com> wrote:
>
> Piotr,
>
> There is no chance this will be reversed. The OAuth will not change immediately, and I'll be happy to work with you individually, but you should consider the 17th as a hard deadline. After this time, the format may change without notice at any time in the future; the format of this string is an implementation detail and should not be depended on, other than the promise that it will always being unique and consistent for a given user.
>
> Some of the reasons for this change:
> • We don't want people relying on the format and it was our mistake for making it simple to intuit that it was an incremental ID. We want to correct that before any others head down this path.
> • UUID is more secure, since sequential numeric IDs can be guessed.
> • UUID is more reliable, for the same reasons covered in our docs on arrays.
> • Changing to a UUID allows us to further scale auth services, since an incremental ID requires all the servers to lock on that ID to increment it and create a new user
> • It's going to allow us to add some new features to our auth services that have been hindered by the incremental ID and scaling limitations.
> There may be additional justifications. These are the ones I've heard in passing conversation during feature discussions. If you have specific concerns, reach out to support; I'm happy to help you work through the changes.
>
> Have a great day,
> Kato

Can you give quick examples of how to get the user’s Facebook ID under the new system in iOS? Probably using the FAuthData to get providerData[@"id”]:

https://www.firebase.com/docs/ios/guide/login/facebook.html

We had some places in our code that looked at the facebook:12345 string past the colon to get the Facebook ID:

#define toUID(id) [@"facebook:" stringByAppendingString:(id)]
#define toID(uid) [(uid) substringFromIndex:@"facebook:".length]

So in Firebase, if we had the user’s UID we could look up their Facebook photos etc. Now it’s going to be a little tricky to get that info. I’m thinking that the users will need to store their Facebook IDs in a public profile node in Firebase if they want other users to be able to see that and look up their info.

I take it there’s no way to get the Facebook ID from outside if all we have is another login’s UID, by design.

Thanks,

Zack Morris

[Kato Richardson]

Hi Zack,

Yes, you can still obtain it on the client by using authData.facebook.id. Storing it in the profile is the correct approach here.

Note that for existing accounts, you could simply write a quick migration script to parse the IDs and add the provider id into the data, and then have new users store it at registration time, which would allow for a smoother migration.

Cheers,

Kato

--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-tal...@googlegroups.com.
To post to this group, send email to fireba...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/CE7CF13F-736E-4DC4-8AC0-9D2ADC331052%40gmail.com.

[Evans Attafuah]

Hello,

Out of curiosity is the code for the latest implementation available to use today?

[Jacob Wenger]

@Evans - We don't have a reference implementation available. In just a couple minutes you can use custom authenticaiton to mock the new response though. Kato put together this gist to help out. Let us know if you need any further assistance.

@Piotr - I would say that consistency in the Firebase Authentication service is a win in and of itself. Ultimately, we want it to be clear that uids are unique identifiers and nothing else. You'd be surprised what bad practices people employ with the existing uids. Our response payload to clients already contains all the data stored in the existing uids. For security rules, we already allow you to get the provider via auth.provider and we will be introducing a built-in way for you to access provider IDs from your rules as well. We won't change the OAuth provider uids until we build that in, which is why we are not changing it next week along with the other providers.

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/d92d2f5a-82e7-4fa0-91ed-02ceef1fed80%40googlegroups.com.

[Piotr Kaminski]

Thanks Jacob, that makes more sense, and I'm glad that "security" isn't one of the listed reasons for the change.  Can you confirm that we'll get at least a few days between the additional auth attributes becoming available in security rules and the cut-over to UUIDs?

At this point, it looks to me like the least intrusive fix for apps that rely on the existing uid format is to 1) switch all security rules to build an old-style uid from the new auth attributes instead of using auth.uid, and 2) have clients overwrite user.uid with the old-style uid in their onAuth() callbacks.  Do you see any issues with this approach?

Thanks,

    -- P.

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/CAGcMwsAG8miYhLdkgaAn1o4nOwCBs7VZ%2Bdvoy59-gD4amoE-kQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

[Jacob Wenger]

Hey Piotr,

I will make sure that we don't change the uid format for the OAuth providers immediately after adding the new auth attributes. If I had to guess, I would expect the change to come a couple weeks after adding the new auth attributes.

I'll follow up on your proposed plan through our thread on sup...@firebase.com. I'll report back here with what plan we settled on so that others can benefit from it as well.

Cheers,

Jacob

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/CANF_M5yU4OXp9f2Ce4DWARgnoScX%2Bi8RrLibhd-LR3gGyHRS1Q%40mail.gmail.com.

[Kato Richardson]

Quick amendment here to those following the thread: We've pushed the release date to Thursday, August 20th. 

I'd also like to reiterate a few key points:  Keep in mind that this will only affect newly created users’ ids and does not affect customers who create their own auth tokens, and we are only modifying email/password and anonymous authentication uids for now. We'll send a follow-up email when we plan to release the changes to OAuth providers.

☃, Kato

[Abhishek Garg]

This is a great news! I was always concerned about the incremental uid being exposed to the users. I was wondering if in my data structure where I am using uid as a key would still be valid, i.e. anything that looks like "$uid" : { }. I guess there are no weird characters in uuid so I should be fine.

Abhishek

[Jacob Wenger]

Hey Abhishek,

Great question! One guarantee we can make is that the uid will still be a valid key. I cannot imagine us ever adding "invalid" characters into the uid to break that guarantee, so please continue to use uids in your path names.

Jacob

--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-tal...@googlegroups.com.
To post to this group, send email to fireba...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/4ce7b7e8-460d-4f6c-a24b-420ba7453376%40googlegroups.com.

[Aron Steg]

Hi Kato et al,

I just received the email today and have apps in the iTunes approval process at the moment. Plus I am overseas. There is no way this could be fixed and tested within a week. 

     A.

On Thursday, August 6, 2015 at 11:57:20 AM UTC-7, Kato Richardson wrote:

[Kato Richardson]

Aron, you would only need to be concerned if you are using auth.uid in any unconventional way, such as those described in the original email for this thread. If you run into any dependencies, feel free to reach out to support!

Cheers,

Kato

--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-tal...@googlegroups.com.
To post to this group, send email to fireba...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/f50e6490-0568-4d0b-b406-1f810a86d195%40googlegroups.com.

[Dean Wagner]

We're using the user.uid from Google as keys for children of a 'users' node. Thus 'google:56532...' Even if we can continue to use user.uid as a key, will the values for each user change forcing us to re-register our users?

[Kato Richardson]

Hi Dean,

This will only affect newly created accounts after the deploy. Your existing user ids will not change.

Cheers,

Kato

On Thu, Aug 13, 2015 at 3:29 PM, Dean Wagner <de...@dfwagners.net> wrote:

We're using the user.uid from Google as keys for children of a 'users' node.  Thus 'google:56532...' Even if we can continue to use user.uid as a key, will the values for each user change forcing us to re-register our users?

--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-tal...@googlegroups.com.
To post to this group, send email to fireba...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/7e831e36-16e1-4b29-a53c-09d1f298c3ad%40googlegroups.com.

[William Summers]

Happy to see this change. Sequential ids have always been a concern for us. Did I misunderstand, or did you imply this would lead to a method for obtaining the user's id without knowledge of the provider? That would be great for mixed auth scenarios.

[Julien Reszka]

It seems that I really didn't understood how we are supposed to check (in the security rules) if (for example) the poster of a post is the same as the person that is trying to edit it. Aren't we supposed to put in the post object the user id so we can check if the user id in the post is the same as the user id of the person that is connected? How are we supposed to do it instead?

[Kato Richardson]

Julien, not really sure what this means. You can continue to use auth.uid in your security rules normally, as long as you aren't doing any sort of contains() or replace() on the value.

--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-tal...@googlegroups.com.
To post to this group, send email to fireba...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/b3ba4a11-9081-4767-bb0d-bfb6a50bd9d6%40googlegroups.com.

[Rob DiMarco]

Hi Julien -

I suspect that you don't need to do anything and your application would continue to work normally. In general, very few developers are impacted by this change at all.

As Kato mentioned, the only instance in which you would have to do anything is if you are parsing apart the user id (`uid` field) rather than using it in its entirety. Any existing rules that check against `auth.uid` as a whole are unaffected. Parsing / splitting that field is where you would run into trouble (auth.uid.split(...) / auth.uid.contains(...) / etc.).

If anyone has specific cases that they're worried about or would like me to review, feel free to ping me off-list. (rob at firebase.com)

Have a great weekend -

Rob

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/CADypTEZxDdvpiUH57RSiL2BXwOxqjSBifnwVh0ZjX43gPKVY5Q%40mail.gmail.com.

[Kato Richardson]

Hi again, 

We've moved the date of the change for email/password and anonymous authentication to Thursday, August 27th. This is primarily to help developers trying to release apps to the Apple store.

To reiterate, this will not affect existing user uids, just newly created users after the release date. This will also not affect OAuth providers. We'll send out a separate notice before that release.

☃, Kato

On Thursday, August 6, 2015 at 11:57:20 AM UTC-7, Kato Richardson wrote:

[Mario Giambanco]

Could you guys please try to work on a means of communicating these changes better to your customers?

I spent 2 hours yesterday testing and modifying my login process (in addition to changes and testing a week ago) in anticipation for today's changes while on vacation in Las Vegas (my first in 3 years) and even woke up early this morning to do additional testing, expecting the rollout to be complete only to find new accounts being handled the same way.

It was only now that I had a few minutes to catch up on tech blogs and news that I came back to this group to see that the rollout has been moved back to next Thursday.

Very inconvenient and unprofessional. I and I'm sure many, rely on your services - it's importance is worth more then 1 email and a google group chat.

... frustrated.

-Mario 

[Kato Richardson]

Hey Mario, thanks for the feedback. We really appreciate hearing your thoughts here and understand your pain. 

The pushback on the release date is in response to feedback like yours; we're working hard to accommodate the small subset of accounts affected by this change and to also promptly release what we feel is a time-critical, reliability-related enhancement. Bear with us and we'll continue to balance those two very important requirements.

☃, Kato

[Laurentiu Morariu]

Hi there. Is this definitely happening today? As I was doing some testing and I don't see any changes.

[Kato Richardson]

Laurentiu, thanks for the ping. It's only 6a here, so it'll be a few hours until the engineers roll into the office and start firing things up. I'll make sure they update the thread with the latest and greatest.

☃, Kato

--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-tal...@googlegroups.com.
To post to this group, send email to fireba...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/1cb736d1-d327-4ad3-ac51-1ea4ff1db726%40googlegroups.com.

[Douglas Correa]

What about a blog post about that?

Just to keep things "officially".

:)

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/CADypTEY-HzPM9Yhoa8xefk9T5U5Bv%3D68LA_qf88jg5wkCWkfFA%40mail.gmail.com.

[Jacob Wenger]

There will not be a blog post, but I will post here once the change occurs later today. We are planning on a deploy during the afternoon Pacific Standard time (PST).

Jacob

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/CAPUi1p1E5i4jX%3DJXSzNybFOXuX%3D64Z8_6HwK8QcgJi0sWPqrdw%40mail.gmail.com.

[Doug Puchalski]

Is there a schedule for OAuth? 

I'm using emberfire, torii, and google for OAuth, so there's no explicit call to createrUser(). Will the criteria operate differently?

[Jacob Wenger]

Hey Doug,

There is no schedule but the change is going to happen. You are correct that there is no createUser() method, but when you call authWithOAuth*(), you get back authData which has a uid in it. The format of that uid is going to be switching to a UUID at some point in the future, so start planning for it now. Ultimately this boils down to:

The auth uid is meant as a unique identifier for the users in your Firebase database, but you should not rely on the format of the uid in any other way, as it is subject to change.

Hope that helps,

Jacob

--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-tal...@googlegroups.com.
To post to this group, send email to fireba...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/848c0c2d-c8d9-4ce8-aba0-b6edf0f8a020%40googlegroups.com.

[Douglas Correa]

Jacob,

One question: the provider field will remain there, right? Just the uid will have the format changed, but any other auth fields will be there, right?

Douglas Correa

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/CAGcMwsAe9XWYgJyjZJddoy43w1smV_soTX1v2JnodYkkqp%2B-6A%40mail.gmail.com.

[Jacob Wenger]

That is correct. The only change that is happening today is that the uid field is going to be in a new format.

Jacob

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/CAPUi1p3FMUKxA2RemVmDsdJ0_%3DS6AqtpcxTKiezLFXQ0mBouGA%40mail.gmail.com.

[Jacob Wenger]

Hey everybody,

I just wanted to let you know that the uid format change has gone live. Please contact sup...@firebase.com if you have any questions, concerns, or need assistance of any kind.

Jacob

[Lynette Artin]

I totally agree Mario - this was very inconvenient and 1 email that I did not see.  I have a bazillion things going on and 1 email and 1 weeks notice is over the top inconvenient.  We woke up to a mess and still trying to work through it a week later - because I missed the 1 email that was sent along with hundreds of others that day.  Now my new users experience has been horrible, and it is impacting everyone so I have thousands of others complaining.  This is why you build everything in house so you are not captive to 3rd party systems that feel 1 email and 1 week is sufficient notice for a change of this magnitude.  Boneheads.  :) I say that in jest - but not 100% in Jest :)

[Kato Richardson]

Hi Lynette,

Thanks for the honest feedback. We love hearing from the community, particularly when we're not meeting your expectations. We're in the business of helping people build amazing apps, and if you aren't experiencing that, we want to do better.

To clarify, we sent three emails:  A automated message to owners of apps actively using authentication of any sort, an automated email specifically to owners of apps who have special conditions in their security rules that would break, and this mailing list announcement, which was only a general announcement to ensure we didn't miss anyone. I see that we failed you here, somehow, and I'm sorry to hear that.

A longer timeline would certainly have been nice, but the nature of this issue required us to move quickly to protect user data and to maintain the quality we demand of our product. We appreciate your trust and understanding that this was important.

Please feel free to reach out to me directly if you want to chat more, get clarification, or vent your frustrations--I'm happy to listen and/or help. 

Have a great day, and I'll work hard to incorporate this feedback into our process for urgent, time sensitive and breaking changes (of which, if my memory serves, there have been exactly one).

☼, Kato

--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-tal...@googlegroups.com.
To post to this group, send email to fireba...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/e8f2d169-b339-4295-a9d6-434ef69c3a77%40googlegroups.com.

[Lynette Artin]

Hello Kato

Thanks for the response - we worked through everything and all is working like a charm.  I only received the one notification - of course it was after the fact - taught me a valuable lesson - sift through the hundreds of emails to find the important ones - I think notifications to devices like my iPhone would be a great idea - and totally understand the reason behind the change.

Enjoy your weekend - sorry for calling you boneheads - although it really was meant as a Smart Alec Joke.

Lynette