I am trying to pull some data from the TSI for a defined time period using python. I would like to do this with the help of access tokens generated for security purposes. Can you help me with how to start this process.
#ranah
How you'll do this will depend on whether or not you want to authenticate a user, a Service principal / application, or via the device code option. Take a look at the Python sample for obtaining an AAD token here. If it's a user that will be accessing the data within TSI then the user should be granted either the Reader or Contributor role. If the app will be calling the API as itself then you'll grant the AAD app a role on the TSI instance just like you would for the user.
In the sample code, replace the value for the resource URI with "https://api.timeseries.azure.com/" The trailing slash is needed.
Once you have an AAD token you can then make calls to TSI's APIs for events, series, aggregates and model metadata.
Useful links:
https://learn.microsoft.com/en-us/azure/app-service/configure-authentication-provider-aad
https://learn.microsoft.com/en-us/azure/time-series-insights/time-series-insights-authentication-and-authorization#service-principal
Related
My team is using Firebase Auth in our project. We're using custom claims to properly authenticate whether or not a user has access to a specific piece of information. We're storing each piece of information and deciding access for the user based off whether or not the user has access to a specific location. Each piece of data is somehow associated with a location, and we are storing the location id in the custom claims for the ID Token.
The problem is that a user potentially has access to thousands of locations. Instead of storing thousands of locations in the custom claims, we think it's better to generate a new custom token and exchange it for a fresh id token every time the user switches locations. That means that it's potentially reasonable for a user to generate a new custom token every few seconds as they switch through their locations if they are doing it quickly enough.
The Firebase Auth documentation doesn't indicate anything in regards to any rate limiting in this regard.
Are we going to run into any issues / rate limiting if a user switches through their locations very quickly? This would be unusual, but I just want to make sure that the worst case will still work.
The control of Firebase Authentication custom claims is an Admin SDK operation and as such is not subject to rate-limiting. Firebase Authentication as a whole is designed to handle millions of concurrent users and is subject to various rate limits. Updating a user's custom claims would only contribute to the overall limits of 1000ops/sec and 10 million ops/day (at time of writing).
However, custom claims should be used for access control related data that will infrequently change such as the name of a role or a building ID. This is because the propagation of changed custom claims can take up to an hour and requires that the client code manually refresh their tokens after any changes to see an immediate effect. Custom claims have no mechanism to notify clients that they have been updated.
I'd reconsider your approach and store the list of locations a particular user has access to in the Realtime Database or Cloud Firestore rather than the ID token itself. You can then use this information to secure their access using appropriate Security Rules for those databases based on their user ID. By configuring a listener to that portion of the database, your client code can be instantly notified when a user gains or loses access to a new location. Additionally, you can poll information from multiple locations at once so you can show information in a notification feed or dashboard - something that can't be done with the claims strategy.
I've developed an app which relies on Firestore for storing some user's data. This app doesn't have any login mechanism, as it uses the device UUID as identifier; we're not managing any sensitive data, btw.
I'm getting daily warnings from Firestore regarding the absence of security rules in my database, but as long as I don't have any login mechanism and my users need to both read and write from it, I can't see any way for implementing a useful security rule.
Is there any pattern I could follow in this situation? Is there any way to create a security rule for allowing to only read and write data created by the same user without any user authentication?
Thanks in advance
It sounds like you want to identify the user, but then without authentication. My guess is that you want to identify them, without requiring them to provide credentials.
If that is the case, you're looking for Firebase's anonymous authentication provider, which assigns a unique, unspoofable ID to each app instance. Signing in anonymously takes very little code, for example for Android it's:
FirebaseAuth.getInstance().signInAnonymously();
After this call completes, the user has an ID that you can then use in your security rules to identify the data from this user.
I have my app set up so that users can use it without logging in. This includes being able to save data. Each device/browser tuple generates a new anonymous user account for storing data.
I'm in the process of adding (facebook) login so that users can make sure their data persists across browsers and devices.
The firebase documentation shows how to handle a case where a user tries to link their account from multiple anonymous accounts and recommends an approach for merging data:
https://firebase.google.com/docs/auth/web/account-linking
My problem with this approach is that it deletes the original account that was linked which essentially boots the first account out of it's logged in state.
Imagine this flow for a single user:
Logs into device A & saves data
Logs into device B & saves more data.
On device A begins "login" flow using facebook for and ends up linking facebook credentials.
On device B they login/link facebook again (linking fails so we must use an alternate method for recourse).
The process recommended deletes the original account generated on device A & they must log in using facebook again on this device.
I've implemented a different process which doesn't result in device A being booted, and instead logs device B into the account generated on device A. My problem with this flow is that I can't delete the user data from device B once I've successfully logged in to device A because I'm using access control rules on firebase so that user data may only be modified by the logged-in user who it belongs to.
potential (suboptimal) solutions:
Delete the user data before logging into the other account but then if it fails at any point user data is lost.
Upon successful login to account A I could then log out, log into account B, delete B's data and then log back in to account A but this solution seems very inelegant.
I'm confused as to why the example in firebase docs seems to have this glaring issue and wondering what the best practice for this situation is.
I got no responses, but I implemented what I find to be an "elegant enough" solution to the problem.
Instead of deleting the prevUser's account & data after succesful login to the other account, I just delete the account:
I implemented a firebase function to handle the deletion of the orphaned user data:
I have an app created with Firebase real-time database and I've created a few users, all with REST methods found here: https://firebase.google.com/docs/reference/rest/auth/
I can get the user info for the current user, but I would like to have a REST endpoint to fetch all the users (UID, email, displayPhoto, name, etc) or at least a user by UID. I haven't found this method in the link above.
I know that there is an SDK to do that (https://firebase.google.com/docs/auth/admin/manage-users), but I would like to do this with REST since the full app is using REST.
Does anybody know if this is possible and has the rest endpoint?
Thank you!
There is no public REST API to get a list of all users. The reason for this is that getting a list of users is considered a sensitive operation, and allowing that from client-side code would be risky.
The common way to implement your use-case is to build your own endpoint, either on a server you already control, or with Cloud Functions. There you can use the Admin SDK to get the list of users, and then return that to your caller. Make sure to limit what data you return and to properly secure that endpoint though, as otherwise you'll be putting your user's information at risk.
I need to get the actual timestamp of the firebase database servers instead of the placeholder firebase.database.ServerValue.TIMESTAMP.
In order to avoid an XY problem, I will provide my two use cases:
a) I have created my own reset password system using cloud functions and JWT. A user requests to reset their password. I sign an object containing their username and the current timestamp(currently using Date.now()) and send it embedded to a link to their email. When they open the link, I need to verify the JWT and also compare it to a timestamp stored under their uid in firebase database. I also update the timestamp in the database so next time they try to use the same token, it will show up as expired(even if the 1 hour expiration I have set for the token has not passed). Is using Date.now() here enough? How can I pass the current firebase time to jwt.sign().
b) I need to store a negative version of the creationTimestamp of all posts in the database for sorting purposes. -firebase.database.ServerValue.TIMESTAMP does not work. What is the correct way to do that?
Google goes through great trouble to make sure all of their servers have times that are as closely synchronized as possible. So, if you're running code in Cloud Functions, which ends up on a Google server, and you want to know the time on another Google server (like your Realtime Database), just use Date.now(). There's no need to use the special database token for timestamp when running in Cloud Functions.
That timestamp token is intended to be useful when code is running on client devices whose clocks may not be very well synchronized.