I am doing the setup of OAuth with Firebase for a Google Actions app.
I chose the Authorization Code Flow and I am following the steps from the doc here :
https://developers.google.com/actions/identity/oauth2-code-flow
Step 4 of Handle user sign-in, there are two ways to create an authorization code.
I prefer the one that use a json to store the expiration date to save a database call in the next step.
Now, I would like to store all the authorization codes generated and I am not sure about what is the best way to do so. My auth codes are very long (170 characters), and I am not sure if it is a great way to store them as Index in Firebase.
Here is what my DB looks like :
I thought about using a hash to shorten them, but I am afraid about hash not being unique.
What would be the cleanest way to store auth codes in Firebase ?
Thanks!
Keys can be up to 768 characters, so using the auth code as a key makes perfect sense.
Using a hash is reasonable since a good hash has a very low chance of collision, but doesn't provide you much additional value in your case and will (slightly) increase computation time and program complexity.
Related
I am trying to build a mobile app which has a NewsBulletin feature using a NoSQL Cloud Firestore. I am trying to get the unique post view by keeping the user's uid into an array called "views" and count it by getting the length of the array. Is this recommendable or are there other better solution for this? Thank you
Currently this is the structure of my database:
News(Collection)
-DummyNews1(Document)
-newsTitle
-posterName
-bodyMessage
-timeCreated
-views(array)
-dummyuid1
-dummyuid2
I like your solution as it is easy to implement. You don't actually have to manually check for duplicate uids, as firestore has a built in feature that does that for you.
Here is an example:
FirebaseFirestore.instance.collection('news').doc('documentId').update({
'views': FieldValue.arrayUnion([viewerUid]),
});
FieldValue.arrayUnion will check if the contents exists in the database, and only when it does not will add the content.
Now, although I am a fan of you solution, and I do use this method for like type of feature in my own published apps, there are some limitations that you should be aware in case your app becomes super popular.
Maximum document size in firestore is 1MiB. Since firebase auth's uid is 28 characters long, that would be about 37,400 views maximum to be stored in a document ignoring other fields.
But if this is a new application, I would not worry too much about this limit. Besides, once you get close to this limit, you should have more than enough resources to pivot to another method that scales.
I am looking at using the Autocomplete API from Here Maps and using the Suggestion.json endpoint. My question is that as a user keys in characters, the autocomplete API for suggestions will be called on every key press. This means that for each key press, I need to call the API. This will turn out to be quite expensive. Assuming, I type in "London", it will call the API 6 times. Is there a better way to do this? Also, is there any option of a session token to be created such that, I get charged only for a session token in which I key in multiple characters for a search suggestion list to be generated?
There are a few things that you can do to reduce the number of calls:
Some places have just short names like https://en.wikipedia.org/wiki/List_of_short_place_names, so you might have to consider even single character names for your autosuggest. So you may consider building a cache of autosuggest keywords i.e. say a user types L and the one time you make a call to autosuggest API, you can cache the result with L as Key and then for the next key press repeat building the data structure or data store per your requirement, so that the number of hits to the API gradually decreases.
Once you have built your cache, you can decide to refresh you cache after every 10 calls or so. This will greatly reduce your call to the external API.
Lookup Trie data structure. might be helpful.
Here bills you based on the number of requests you make to the backend services so there is not such possibility to bill by session token. You can talk to your account executive if you can negotiate the cost of the offering though.
You can do this pretty easily with the Javascript API: here's an example to get started and here's the documentation page for autosuggest Javascript API.
I'm working on a chat client using the firebase realtime database as the database. The way that it currently works is that it saves a chat log between two people in a chat collection with each entry in the following format <uid>-<uid>. This works great as it just looks your uid and the uid of the person you want to chat with and then sorts them, so it's always a consistent format and then it looks if that entry exists on the chat collection and if so, it just adds to that entry. Otherwise it creates a new one.
This works awesome. I'm trying to think ahead though if we want to be able to have multiple people talk together like in slack. I could just add 3 or even 4 people's uid as the key but eventually it's going to be insanely long. The limitation of a firebase key is 768 Bytes. Apparently that's somewhere between 500 and 700 characters. I doubt we will have the key get that long, but if we can figure out a solution that is more scalable now and won't require us to fix our data later, i'd rather do that.
I was thinking that each chat entry could have a participants array with the uid's of all the users in that chat. Then if you want to chat with someone, we would need to query all chat entries and check the arrays in each of them for the current user uid and the uid of the person(s) they want to chat with. That doesn't seem very efficient though.
Any thoughts on which implementation is better / more scalable / performant? Or perhaps a suggestion for another implementation?
How about simply using the hash of the resulting concatenation of UIDs?
Alternatively:
Come up with your own unique room key, e.g. using a push ID.
create a new top-level node with chatroom-keys and store the concatenated UID as the value there:
chatroom-keys
push-id1: uid1-uid2-uid3
push-id2: uid1-uid2-uid3-uid4-uid5-uid6
push-id3: uid3-uid4-uid5-uid6-uid7-uid8-uid8-uid10
In this structure you can look up the room key for a set of participants by:
firebase.database().ref("chatroom-keys").orderByValue().equalTo("uid1-uid2-uid3")
Based on what i know (correct me if i am wrong) the 'access_token' is equivalent to the 'protected ticket' field in AspNetUser table. It's just hashed.
What i am planning to do is deserialize the protected ticket to get the access_token value.
I am trying to support a SSO scenario wherein, the user can access multiple application using the same access token.
Unfortunately, if the hash function used is a cryptographic hash, which the circumstances suggest, this is definitionally impossible (or should be...). Cryptographic hash functions are designed to be extremely expensive (ideally impossible) to reverse, and so the most effective method you have would be to attempt to brute-force the hash, I.e. running inputs through the hash function until you get one that produces the output you want. Even then, there's no telling how long it would take you to find it. It is strongly recommended not to write anything that depends on routinely brute-forcing a cryptographic hash.
Of course, its possible that the possible inputs are incredibly small (I.e. at most 16 bits or so), or that the function used is not a cryptographic hash function (I.e. its something like base64 encoding or rot-13). In that case, you might have a method to reverse the "hash" efficiently.
However, I strongly suspect that is not the case. In this endeavour, I think you are simply out of luck, and will have to find another way to get the functionality you desire.
I think I'm a bit late, but it should be possible. The data of ProtectedTicket will be secured by Microsoft.Owin.Security.ISecureDataFormat.Protect. It's not a one way hash. So it can be reversed. You can look this up on Github in the Katana project (Microsoft's Owin implementation):
https://github.com/aspnet/AspNetKatana/blob/dev/src/Microsoft.Owin.Security/DataHandler/SecureDataFormat.cs
As you can see, this interface provides a method Unprotect also. Didn't test it, but you could give it a shoot.
you can use the same token on the same apps as long the jwt token is signed with the same credentials (audience and secret) on every app. This allows every app to verify that the token is valid. this means, how-ever, that every app must know audience id and secret in the backend
Just trying to do some security on my website and trying to figure out the best route to secure an ID.
EXAMPLE: localhost/page.php?user_id=1 TO: localhost/share/df9sdf87423498asf9
That's not security, that's security by obscurity.
Proper security requires that on your server side in page.php, verify that the currently authenticated user has access to the given ID.
If you don't use authentication and pages are only intended to be viewed once, check the answers to this question for a random number generator.
You can look into using UUID instead of auto-increment user ids.
Edit:
To be clear, this is by no means "encryption". It is simply an alternative way to using 1,2,3,4... as primary key for users' table. Bare in mind that using UUID instead of incremental numbers will result in higher I/O because insertions are going in random locations in the index tree, not sequentially as the incremental ids.