Im trying to create users in mesibo as some big unique numbers as follows -6044:6003:7aa7ec39a119410da93c109c6b8c4c5e
But looks like these users are not able to send & receive messages.
Please help me is there any format restriction to create users address here.
Is it valid user address - 6044:6003:7aa7ec39a119410da93c109c6b8c4c5e ??
No restrictions as long as it is a unique string and does not have HTML symbols for security reasons, it is mentioned here.
https://mesibo.com/documentation/faq/#is-it-required-to-have-an-email-address-or-a-phone-number-to-use-mesibo
Absolutely not. You can use any valid random string as the user-id.
All you need to ensure that the user-id is unique across all your
users. Refer to the mesibo backend API to learn how to create a user.
Try without ":" and see that it works.
Related
Firebase is great as it offers a lot of authentication providers. In one of my apps, I use four different providers provided by Firebase (Email, Twitter, Facebook and Google), but I also need to let users sign in via LinkedIn.
As Firebase SDK does not offer LinkedIn, I need to implement the login flow manually, which doesn't seem to be difficult, but there is one huge issue which I see. During the creation of a custom JWT token, I need to assign a user ID. And I have no idea how to generate one while making sure that my approach will not conflict with user IDs which Firebase generate on its own for other providers.
For example, let's imagine that a user Andriy Gordiychuk signs in via LinkedIn and his email address is andriy#gordiychuk.com. A simple way to create a user ID would be to take an email address (andriy#gordiychuk.com) and to randomise it using some hashing function. I would get some random id such as aN59nlphs... which I would be able to recreate as long as the same user signs in. So far, so good.
However, how can I be sure that the ID which I get is not already used by another user who signed in via Twitter, for example?
One way to mitigate this issue is to store LinkedIn user IDs in a Firestore collection. Then, when I need to create a token, I first check whether I already have an ID for this user. If not, I would hash the email address, and I would try to create a user with this ID. If this ID is already occupied, I would then try to create another ID until I stumble upon an ID which is not occupied, and I would then use it.
I don't like this approach for two reasons:
Although the chance that I would generate an already occupied ID
is small, theoretically the process of finding an "available ID" can
take a lot of steps (an infinite loop in a worst-case scenario).
Once I find an available ID, I must store it. Given that all these calls are asynchronous there is a real chance that I would create a user with a suitable ID, but because the save operation fails, I would not be able to use this ID.
So, does anyone know how to choose user IDs for such use case correctly?
It's fairly common to generate a string with enough entropy (randomness) to statistically guarantee it will never be duplicated. This is for example behind the UUID generators that exist in many platforms, and similarly behind Firebase Realtime Database's push keys, and Cloud Firestore's add() keys. If there's one in your platform, I recommend starting with that.
Also see:
The 2^120 Ways to Ensure Unique Identifiers, which explains how Firebase Realtime Database's push() works.
Universally unique identifier, Version 4 on Wikipedia
the uuid npm module
If I am storing something in Firebase and the key of that is something like -L1gMGVKaj-qU8O05eeT, is it safe to create public URLs like http://example.com/item/-L1gMGVKaj-qU8O05eeT?
Is it safe to distribute internal push keys to public, provided that proper database rules are in place?
There is no security issue in using push ids/keys in public URLs provided that your credentials (e.g. Server Keys or Service Accounts etc) are safe and not viewable.
However if you want that users should not be able to guess other push ids/keys then you should check this Answer
You can create your url using the keys generated by firebase on basis of timestamp. But it will not be user friendly. you can convert the key to unix timestamp and then use it for url. Look at this answer
Somehow I still have a understanding problem with firebase rules and need some input from you guys.
Lets say I have a user node with all my users. Each user contain sub-nodes for things like email, name, phone etc.
My basic firebase rule says now that only the user with the correct id can edit/write/read in his own node. This works all fine. But now I do have situations like another user search for a friend and there for I need to search for example in all my users for a name or email BUT since my rule does not allow to read userdata except if the user is the owner of his own data I dont know how to solve this. I cant use a rule to give every authenticated user READ rights for the other users data BUT I still would like to search for example for a email address in the other users data. This confuses me all a lot.
The only thing I can think of is to run parallel a complete separated list with something like public informations and keep the rule that everybody can read (not write) in this list. BUT THEN again I have the issue that somebody could easy access my entire user-list (emails for example) if I keep them inside the public list.
I would be happy if somebody can point me into the right direction. I have no idea where to start to set this up from the start correct.
What is the best approach to do something like this?
Hey I'm not a pro or affiliated with Firebase. But as I have encountered same type of problems I share my thoughts with you.
I don't think allowing users to search others based on emails stored in a Firebase node and directly from client side is entirely safe. Searching based on somethign like userName is ok because it is scoped to your app.
If you must, then I would either make it a 2 step process using Firebase functions (which you can put another layer of security check in there also no user is directly reading from database) or introduce other parameters that all need to pass for a successful query. Something like a temporary unique id that expires after awhile.
If you still want to share emails, you can store user's sensitive information in a separate node and only save what you really need to expose to others in a public node which can still have some security rules protecting it form access of someone who is not logged in, for instance and you map the emails by UIDs.
Just some thoughts.
EDITS
You can provide a way for users to be able to search others by username (similar to instagram for instance.) and in firebase you only have to connect each username with their UID. So people can find each other via username. Imagine this in firebase (you can do the same of emails so a person making request need to know an email to get UID not the other way) :
user_names : {
alice_d: UID,
bob_ross: UID,
....
}
You can later search for any user name without exposing others simply by using .equalTo() in your query or run more complex queries via FireStore (I am new to it too) or using a search system that has your data indexed already like Algolia.
Facebook provides further information such as list of friends if you app is approved so you can always use that list to suggest friends granted that users have logged in by Facebook O'auth and your app has the priviledge to see friends lists.
See here for how to verify a user making https requests in Firebase functions. In your function you can do the search and only return what is safe back to the client. (keep in mind the speed might be an issue unless your function is running frequently). And for making the request from client side, you do something like this.
_makeRequest: function() {
this.user.getIdToken().then(function(token) {
//token is a long string JWT token used to identify the user to a Firebase service.
var req = new XMLHttpRequest();
req.onload = function() {
/*you return the result in your function*/
if (JSON.parse(req.responseText).rslt === "SUCCESS") {
}
}.bind(this);
req.onerror = function() {
}.bind(this);
/*attaching location key*/
req.open('GET', 'https://us-central1-rest-of-function-address-found-in-
firebase-functions', true);
req.setRequestHeader('Authorization', 'Bearer ' + token);
req.send();
}
You can also make this happen by writing something to database and have a function to run onCreate(), see here if you need more info on Firebase functions. Hope this helps.
If you want to allow any user to find any other user by their email address, that means that users must be able to read email addresses. If you don't want them to be able to read the full profiles, you'll want to set up an extra data structure that maps email addresses to UIDs:
emails: {
"theeben#domain,com": "uid5601401",
"puf#theotherdomain,com": "uid209103"
}
With this structure you're only exposing the email addresses.
But to be honest, that is still exposing quite some information about all users. Nowadays, I'd consider implementing the search using Cloud Functions for Firebase. That way your API is a function findUser(email): uid type function, exposing only the minimal information.
I am working on one asp.net mvc project. In which I want the facility of customer feedback. Suppose I have sent email for getting feedback on our services. So we are sending emails to customers. They gives answer via Reply of that email. And we want to save that reply automatically in database tables. Its sure that we will receive email on one our fixed email address.
So basically i want to store the reply of email from customers into the database with that customer email id. please note here Customers reply email id will be the unique customer field for me.
Is this possible? How can i achieve such functionality? Please suggest me.
Thanks in advance.
Saving email replies has nothing to do with asp.net mvc per se.
having said that, here are some solutions that you can evaluate:
assuming all the replies go to a designated mailbox (Exchange or whatever), you can setup filters (e.g. VBA files in Exchange) which can intercept the incoming emails, parse them and save it to the data base.
if you don't want to mess with mail server native filters, you can write an offline utility (C# console app, windows service, powershell script etc.) which can query a Mailbox and parse the emails and save it to the database.
All of the above approaches have their pros/cons based on ease of installation, logging, maintainability etc.
p.s. please discard the below if it doesn't make any sense for you.
an uber advice i have always received for customer feedback design problems is to get as much objective data as possible. (as opposed to unstructured textual content in an email) and to get objective data,
one option is to have a feedback form on the website where users fill in definitive fields and you can save the information in a very structured and objective manner.
another option is to send them an email with a link to the feedback form on the site, so that if not immediately, they can leisurely come back to the same site and you collect objective data the same way.
saves you the trouble of parsing emails, trying to save email documents, parsing html/string contents, manual intervention to interpret sentiments of the email etc.
I'm building a public website which has its own domain name with pop/smtp mail services. I'm considering giving users the option to update their data via email - something similar to the functionality found in Flickr or Blogger where you email posts to a special email address. The email data is then processed and stored in the underlying database for the website.
I'm using ASP.NET and SQL Server and using a shared hosting service. Any ideas how one would implement this, or if it's even possible using shared hosting?
Thanks
For starters you need to have hosting that allows you to create a catch-all mailbox.
Secondly you need a good POP3 or IMAP library, which is not included AFAIK in the .NET stack.
Then you would write a Command Line application or a Service that regularly checks the mailbox, pulls messages, inserts content in db based on the "To" address (which is unique for each user), and then deletes the email from the mailbox.
It's feasible and sounds like fun. Just make sure you have all you need before you start!
If the data is somewhat "critical", or at least moderately important, do NOT use their username as the "change-data-address". Example: You might be tempted to create an address like username#domain.com, but instead use username-randomnumer#domain.com where you give them the random number if the visit the web-page. That way people can not update other peoples data just by knowing their username.
E-mails can be trivially forged. I would only do this if you can process PGP / SMime certificates in your application.
Other than that, I see no reason why not!
use a dotnet popclient to read the incoming emails, parse them for whatever you are expecting and insert the data into the database.
see codeproject website for simple popclient implementation
you would have to decided on the email content yourself, eg data only, payload of sql statements, etc
You could also identify the user based on sender address. This is how Tripit (and probably others) does it. This only requires one e-mail address on your end.
I have done something similar, using Lumisoft's IMAP client and scheduling a task in my app that checks every x minutes the configured mail address for updates. For scheduling I recommend quartz.net. No launching external processes or anything.