User ID #170
Comments
|
And please.... do not close this ticket with a "Its not supported yet"... if that is a case please put on the main page of your SDK... "THIS SDK IS INCOMPLETE!" so that people like me can stop wasting this time. The example is also out of date and broken. |
|
Well, it seems my responses to other tickets asking the same things have been removed? My issues are almost certainly with the documentation. As I read it I find huge holes and a few contradictions. Im more then willing to fix them, but I can't if I can't get the answers myself. Its why I went to look at previous questions. Unfortunately, what I am getting from the previous questions is one of three things..
This is very confusing. There is some mention of the UserID not being the same as the serviceID? There is no distinction or explanation of this in the documentation. I can't find how to get either ID. It also seems that the terms used to explain these things changes in the documentation so the "idTokenString" is refered to as something unidentified. I can't set this.... The documentation in the code is lacking. Entire functions, classes and other things have no description or comments making it hard to find any answers. Also the example has things like $idTokenString = "..."; which if used would throw the error that is also asked in a different closed comment with a cryptic response as the solution. In some of the code you use... $idTokenString = 'eyJhbGciOiJSUzI1...'; which also throws errors. So I don't know how to fix these things. There is no explanation that I can find. So Im left without answers and an SDK that if I was to believe what Im given... Will be left with one conclussion. This SDK is unusable because it contains inadequate documentation or that it contains accurate documentation and that we cant get these values we don't have unless we have those same values. (this is impossible). Or we have to throw away the entire webUI and build it from scratch. This would be sad. :( What we need to understand is HOW to retrieve the authentication from the javascript. In one previous post you said we need to present the user with a login and capture his information then send it to Firebase to process. Unfortunately this means that the entire web ui provided by google is unusable with your code? This cant be... It would also be nice to have an example that works.... Especially since the same three questions keep getting asked over and over again... Maybe we can stop this if we had a bit more extensive examples? Or maybe we can stop this if we address this documentation issues? |
|
BTW, I have ALSO checked your test cases. Unfortunately ALL of the test cases retrieve this UserID by creating an account. None of them get the userID of the current logged in user or provides any solutions for the function to work with the webui. |
|
Hey Michael, thank you for taking the time to describe your pain points with this library. I will try to address all of the topics you addressed. Please be aware that this is an Admin SDK. The first line of the official documentation from the official Admin SDKs (https://firebase.google.com/docs/admin/setup) states "The Admin SDK lets you interact with Firebase from privileged environments to perform actions like [...]" (emphasis by me). This means that you are accessing your Firebase project with admin privileges, as if you would access a MySQL database or a Linux system as the root user, and this implies that the implementing user knows what they are doing and how Firebase works, and that they know what it means to give a normal user access through the credentials of the root user.
This library assumes that you (not you specifically) know the concepts of Firebase, what an Admin SDK and what its purpose is. That's why the documentation lacks details in describing concepts - and to be honest also, because I didn't want to duplicate the very extensive official documentation which would be quite time consuming (more about that later).
Previous versions of this library were advertised simply as an SDK, not specifically as an Admin SDK, because back then, it was possible to login a user with email and password, and only with email and password. Back then, I got support requests in the Firebase Community Slack and via email that people wanted to sign in with Facebook, Google, etc. which was simply not possible via the REST API. It has been made possible by Google by now, but back then it was an additional reason for me to decide to go into the "Admin only" direction (and by the way, when I did, the official Admin SDKs didn't even exist yet. And it makes sense: PHP is a backend language running on a privileged server. Firebase is an application platform concentrating on the user experience. Developing a "homebrewed" authentication flow by proxying user credentials through the backend SDK would always be a poor and insecure solution compared to the official authentication flow (https://firebase.google.com/docs/auth/). This is why this Admin SDK allows creating custom tokens and verifying ID tokens just like the official Admin SDKs do (see https://firebase.google.com/docs/admin/setup, the lines "Token minting and ID token verifications" in the feature table), but not more. The user flow is handled by the Client SDKs which run in a browser or mobile app. That being said: you can get the user ID from an ID token created by one of the client applications by verifying that the token is valid (meaning: not forged by an unauthorized entity) and then retrieving the included user id from the token claims as described at https://firebase-php.readthedocs.io/en/stable/authentication.html#verify-a-firebase-id-token - the documentation was missing this information, but I added it in 965e25e The fact that the user's ID token has been sent to your server in the first place is then the indication that the user is currently logged in. In addition to that you can retrieve the user's last login time from the resulting User Record (http://firebase-php.readthedocs.io/en/latest/user-management.html#user-records). If you want to manage users in general, there are several possibilities:
It's not possible to search for users (yet), because the Firebase REST APIs don't provide this, but at least the official Admin SDKs can't do this either :).
Thank you for the hint, this is now fixed with 67d5fb9
The example is just an example and works just fine with the modifications that I assumed were clear to make, like modifying the database URL or the path to the Firebase credentials file. Nonetheless you are right that it's better to be safe than sorry. This is hopefully fixed with e75803a
When I close an issue that requests a missing feature, this means that there already is another open ticket for the same feature. If that is not the case for a given issue, please point me to it so that I can re-open it or create a new issue for that feature.
The reason for this is most probably that the solution refers to a previous major release. I strictly follow Semantic Versioning, that's why I ask for specific version information when an issue is posted here. If you find a solution that works for version 2.x, but not for 4.x, please open a new issue so that I can provide assistance.
Please point me to the contradictions and I will do my best to clear them up. I already addressed the user IDs.
Concerning the Concerning the lack of documentation in the code: There are certainly places here and there where the documentation could be improved, but my opinion is that I don't need additional information if a method name is self-explanatory, the parameters are type hinted and/or the code is easily parsable. You may disagree, but this is how I roll. But by all means point me to code that you consider unclear and I will add documentation if I agree with you.
If I said that you should create a custom web UI, it was probably related to a previous major release of this library when I wasn't focusing on Admin tasks or at a time when Firebase didn't yet provide a unified login UI. Please know that I started this library when Firebase was still a company on its own and not part of Google. A lot of improvements have been made since, and a lot of my answers to older issues are as obsolete as the state of affairs at the time I gave them.
Each test is self contained, and before I can test a user, I have to retrieve it. I can't retrieve it if I don't know its ID - that's why I create the user, test it and then delete it to not pollute the user base of my test project.
I can assure you that I haven't removed any response to any ticket.
I honestly am sorry that you feel that way and felt the need for you at times aggressive tone. I don't agree that the SDK is unusable, and I'd like to believe that the amount of Github stars, downloads and positive feedback that I received via Email, Twitter, Github ❤️ and the Firebase Community Slack confirm that it actually is usable and useful.
I will continue to close tickets that ask for features that are not supported yet and if there's another issue for the same feature - and now I'm coming to that "more about this later" stuff: I am writing, maintaining and providing support for this library in my not so extensive spare time and I'm not being paid for it. I don't say this to complain, but I want to make clear that I do all this on my terms and how I want to and can do it. I don't claim that this SDK is as feature complete as the offical ones, but I will also not capitalize on the fact that it isn't, and please remember that I'm not Google, I'm just a single developer providing an SDK for PHP (and to be honest: the only one that works and is up to date). The documentation includes everything that is possible and nothing that is not possible, the Github issues page is my roadmap for the library, but I can't and won't give ETAs of upcoming features - unless someone offers me adequate compensation for a feature (you as a freelance developer certainly can relate). My docs are certainly not as good as they could be, but they've done the job (until today that is), and they're the most time consuming part, because I am a coder, not a writer. I am providing this library for the sake of open source, because I can decide on how to do what, and of course also for my own fame and vanity :). That being said: I do appreciate every pull request and issue pointing to an error in this library. If you think this library is lame, help me make it better and propose a pull request - I can't promise that it will be merged (in fact, it probably will not unaltered because of my own coding standards and because I have to maintain the code afterwards), but that's where the open source aspect takes effect: if you find the library unusable, fork it and change it to your likings. If it wastes your time, by all means, don't let it waste your time and use another library, and I write all this with the most positive intentions. I hope I have addressed all the points you made, please let me know if I have forgotten something. I invite you to join the #php channel in the Firebase Community Slack where you can find me to discuss this further if you want, and other PHP developers using Firebase - the channel is quite quiet, but it is something. Cheers! PS: One of the pain points you mentioned was outdated comments on older issues. As I said that is why I am asking for a version number in the Github issue template. You provided "latest" which will be incorrect as soon as 5.0 is released and could (in theory) trigger a response from somebody pointing out that my comments are not accurate. ;) PPS: I would normally close this issue now and say that this doesn't mean that the discussion is over (that is what lockdowns are for), but for the sake of one of your points, I will keep the issue open until you close it (or after some time without activity) |
|
What you are doing is definitively usable and useful @jeromegamez :) |
|
Thank you for your detailed response. I'll write more in a bit as I get working on the specifics of your response. I just wanted to let you know that im frustrated, but not at you. please understand that I'm struggling understand the workflow required. Your post helps clarify that. As I figure this out ill make more submits to the docs. I understand that its hard to write this all alone as you don't Have the perspective of someone new. So if you continue to be awesome then ill be happy to pay it forward. Honestly, this is Google's responsibility, but unfortunately that don't matter when there business to be made and your stuck with few solutions. And yes, I fully appreciate your time. Very happy you understood that my frustration was not directed at you. I've contributed in the past to these projects, and i hope to help solve these small issues with you so that no more users come to these tickets with these issues. (i know pipe dream, but lets try) so thanks for your time. |
|
Ok, one of the root causes of this is because we are stuck in ID/token hell. Its REALLY hard to know what ID and what Tokens do what. Leaving the $idTokenString="..." is part of this problem because "..." doesn't even give an idea of what this thing looks like. Might be nice to put a dummy value, or just not define the $idTokenString at all and just use it, then we take the next step in fixing it. Consistency seems to be pretty good, but there is no where I can look these things up. One of the solutions I think is to create a "Index, Annotation and Definitions" Page in the doc. With this we can then define these variables more extensively. The entry on this index page will thus be "$idTokenString" - This variable in our examples is a string populated with... and retrieved from... Google references this variable in their documentation at https://firebase.google.com/docs/auth/admin/verify-id-tokens. Examples of this string will look like... "$userIdString" - This variable in our examples is a string populated with the User ID string. This is retrieved from the web UI javascript provided by google and is found by first calling X function then defining Y. Please see the API code on the Authentication Page and Googles script tags can be found here. (there are more we can add here as well) Also, what you said above about the workflow is amazing. It would help so much if we could get a workflow page in the documents as well. Or maybe just a section. The reason why you choose the name "Admin" should also be in this page. That was really a cool insight that we shouldn't loose. I was curious if the "Admin" meant that this library provided a MyPHPAdmin type utility. I never thought that it meant that we logged in with a super user. I see many people struggle with the concepts your addressing and part of the problem is that using PHP on a server is very different then using this code in an APP. Googles docs tends to mix these things together in their documentation because they need to handle both. Its thus very hard to sort through what is for App development and what is for a trusted web server. This ambiguous nature makes it hard to search for answers and find ones that apply to what we're doing. Luckily, this SDK is always from the server perspective and we can thus take advantage of this. We can then be very clear and definitive. Another area I struggled with is how (or even IF I needed) to integrate the WebUI with your code. I can see that it would be nice to have some code that could help us generate the script we need for login in. But that's not even 100% necessary. Truthfully, it would be nice to just see this client based javascript talked about in the workflow. Something like, "The user retrieves the page with the script login functions found at... where he is prompted to login or register. This login will thus take place entirely on the client side and will provide our server with the ?UserTokenString?. This Token can then be retrieved with the X call found in the documentation here." (I figured ?UserTokenString? is the wrong term, please replace with your term, variable or function name. I think if we add these few sections we will definitely reduce the amount of confusion. Let me know what you think, and if you need some help writing, reviewing, etc... I have no problems putting in my part moving forward. Again, Thank you for your time on this. P.S. Goyavo, Couldn't agree more. I apologize for my harshness in my first post. It was certainly not my intention to express any other idea. |
|
BTW, the graph... AWESOME! Did you just add that? |
|
I have pushed a small change in the docs. Its in a fork. Let me know if you got it and any feedback you got. I will continue to make additions. Im still confused about the workflow and that $idTokenString. Is this the user ID, or the service account ID? I figured it was the service account... but I don't see any examples linking the service account to this ID. Or is it an ID string set in the firebase UI? I followed the link you provided and included it in the links above... I understand the workflow, I just don't have the proper terms associated with the proper parts of the workflow. Its why the Index above would help. I could then know that this $idTokenString was the admin. Once I understand it, I can finish the above doc changes and submit a fork for that as well. Ill even link all the spots in the docs to this index if we can. I hope this is welcomed. Let me know if it isnt. |
|
@MGParisi Would you be okay with closing this issue for now? FYI: with the release of 4.2.0 I have also started a new repository at https://github.com/jeromegamez/firebase-php-examples - there are just a very few examples yet, but I am sure the repo will grow with time :) |
|
Thank you to all that participated in this conversation that helped clearing up/understanding several points and (I hope) led to some small enhancements in the library. I will close this issue now as there is no immediate steps to take to solve a concrete issue, but feel free to add further comments or to create a new issue if needed. |
|
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
1. Which version of
kreait/firebase-phpare you using?latest
2. Which version of PHP are you using?
7.1
3. What's the issue?
No user ID... No way to identify user? No way to know who is logged in? What?
Im reading these tickets about the user ID... It says the API does not allow you to get this? Then how are we suppose to use the API that REQUIRE this? We have a huge hole in the documentation, the API and the usage. It seems ridiculous, but unless I use the asuser, their will be no security. Wow...
BTW, the install command using composer is wrong and will not work in all installs. Specifically the .lock file exists. Sorry, but remove the php from in front of composure and the extension of the file.
Not entirely certain how to get this working... Kinda lame as Im just wasting time now.
The text was updated successfully, but these errors were encountered: