Imagine that a database connected to an XMPP server stores users, it also stores an extra data column (let's call it dataId) for each user. The data column can take on three values: 1, 2, or 3.
In an XMPP client that logs in to the server, a list of users is displayed along with their XMPP presence status. The list displays users that all have the same value of of dataId. The client can change the dataId value that is displayed, meaning that if he switches the value, then the user is now somehow subscribed to the presence of the new list of users, but not to the old list of users.
I wonder if someone with experience with XMPP has a suggestion as to which XEPs or corresponding eJabberd (or Prosody) modules could be used or are best suited for this type of functionality.
I am slowly going through the XEPs, but there are a lot of them, and it's not clear as of yet which modules could be used, or if I would perhaps need to set up some custom code on my XMPP server to handle this.
You can take a look at XEP-0140. This behaves similar to rosters except that all users in a shared roster group will be able to see all other users in the group. You can create multiple shared roster groups and easily switch a user between them by adding or removing the user from the group. You can also have nested groups. You can look at the example on using shared roster groups for different cases here, using ejabberd.
I have a web app that you can currently log into with either your email address or your username.
I'm developing an iPhone application and I'm just wondering if I should offer the ability to log in with your phone number. If this is the case, a user would first have to provide the service with a number on the web (an optional parameter).
I find it convenient on other services I use where I might not remember what email I have connected to it.
Is this a good idea?
Would you offer it in a service you were
building?
I'm trying to decide if its worth the trouble to build.
NOTE: This number would strictly be used for authentication.
I think that if your service is not about phone numbers (calling, texting, etc., e.g., whatsapp, etc.) I would not add phone number authentication for a few reasons:
Some users might be deterred to provide a phone number due to privacy concerns (no matter how hard you try to explain them that you will keep it safe)
With the phone number you will now have 3 options to login with, which is way too much. You want to keep your mobile login screen very simple
Some people may think that they might get SMSs from you or get their phone bill charged somehow
Overloads your backend
Just keep it simple...:)
To add to that, I personally prefer just email, without a user name. So many sites require user names AND impose restrictions on how this user name should be structured, so you end up with tons of them. With emails, you can't go so wrong - most people use a primary one to sign up for sites.
Hope that helps.
In my IRC Bot, there are some commands that I want to only be usable by me, and I want to check to make sure that anyone using my name is identified with nickserv (idented). I couldn't, however, find an easy way to determine this, which is why I'm here.
Freenode and Rizon are the primary target networks, if that matters.
Edit: I was actually aware of the various usermodes for idented users (although I didn't pay enough attention to realize that they differ!); sorry for not mentioning that before. The raw response that I get from a user, however, doesn't include their usermodes; it looks something like this:
:liam_neeson!n=pearson#71-9-55-124.dhcp.snlo.ca.charter.com PRIVMSG #erasmus-testing :foo
I suppose, then, that I'm trying to find a way (with various ircds, grr) to get those flags. If, as someone mentioned, Rizon returns whether or not someone is idented in a WHOIS query, then that's the sort of thing I'm looking for.
On freenode, sending a private message to nickserv with the message ACC <nickname> will return a number that indicates the user's ident status:
The answer is in the form <nickname> ACC <digit>:
0 - account or user does not exist
1 - account exists but user is not logged in
2 - user is not logged in but recognized (see ACCESS)
3 - user is logged in
The STATUS <nickname> command gives similar results on Rizon:
The response has this format:
<nickname> <digit>
0 - no such user online or nickname not registered
1 - user not recognized as nickname's owner
2 - user recognized as owner via access list only
3 - user recognized as owner via password identification
The advantages that this method has over a WHOIS:
Information about ident status is always included. With WHOISes, you will just not get a line saying something along the lines of "identified with nickserv as such-and-such" if the user is not, in fact, idented.
Consistent number of lines returned. Since I want to grab the message before passing on control to the rest of my program, I can easily read one line out of the buffer (I see synchronization issues in your future!), determine the status, and continue on like normal.
On some networks you can enable a feature called 'identify-msg'. On FreeNode you do it by sending "CAP REQ identify-msg" and "CAP END" when you first connect to the server. The server will respond with a reply confirming that feature. Afterwards, all messages (and CTCP ACTIONs) will be preceded with a "+" (user has identified with NickServ) or a "-" (user has not identified with NickServ), e.g.:
:liam_neeson!n=pearson#71-9-55-124.dhcp.snlo.ca.charter.com PRIVMSG #erasmus-testing :+foo
Nick registration is not part of the IRC standard. It is always offered by customized IRC servers and/or bots. I don't think you're going to find a truly universal solution, but NickServ is a common available implementation, which would work on many networks. Wikipedia has more info.
You may want to sidestep the problem entirely and have your user register with your bot, instead of with nickserv. Your bot would then do the password checking, and would invalidate the user's credentials when the user logs out. This would be a universal solution.
As your username is registered, before your bot logs in, you do this command:
/ns ghost username password
This command will remove any user that is logged in on your user, remember that I only used this in Freenode, I don't know if it will function on another server.
With Freenode, if a user is identified to NickServ then their user has the +e mode set. Not sure if Rizon has something similar.
UnrealIRCd and hybrd set +r to registered users, I'm not sure if all IRC servers do this though, it's pretty unstandardized. Also on Rizon you can whois and it will tell you if the user is registered.
/NickServ INFO <username>
This will tell you whether the user is registered or not.
I discovered the command via this site: http://www.deepspace.org/nickserv.htm
I have got an Openfire Jabber server with in excess of 75,000 users listed. Of those, 150 or more can be online at any one time.
Is there anywhere that I can collect the JIDs (usernames) of the currently logged in users? I have full database access to the underlying data, but the server does not appear to write the current status back to the DB. Because of the number of users, rosters are not being used.
A very useful set of data being returned would be from a simple (password protected) webpage with one JID per line, optionally with the login time, and maybe also the last time that account performed an action [like send a message]. The latter two are not as essential, but would be useful if the data is available, as well as any other information that was available regarding the user session.
dont know if this will help but I ran into it looking for similar functionality. As defined in XEP-0045 http://xmpp.org/extensions/xep-0045.html#disco-roominfo :
An implementation MAY return a list of existing occupants if that information is publicly
available, or return no list at all if this information is kept private. Implementations
and deployments are advised to turn off such information sharing by default.
So you would need to ensure it works as advertised on Openfire (all xmpp servers ive come across have a bug or two in them), and I imagine you would need to code some logic to get the results.
Good luck.
Not a perfect answer, but the query you want is probably embedded in the session-summary.jsp page. I got to it on a locally hosted server at http://localhost:9090/session-summary.jsp. What I don't know is if that is then stored in the database where it is query-able, or if it is stored internally to the client. The latter is more likely.
The data that page displays is Name, Resource, Status, Presence, Priority, Client IP, and Close Connection.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 months ago.
The community reviewed whether to reopen this question 3 months ago and left it closed:
Original close reason(s) were not resolved
Improve this question
I'm creating a web app that requires registration/authentication, and I'm considering using an email address as the sole user id. Here are what I see as the pros and cons (updated with responses):
PROS
One less field to fill out during registration (it would just be email address, password, and verify password). I'm a big fan of minimalistic registration.
An email address is easier to remember. (thanks Mitch, Jeremy)
You don't have to worry about your favorite username being taken already - you're the only one who uses your email address. (thanks TStamper)
CONS
User has more to type every time they log in.
What if a user wants multiple accounts? They'll need another email address. (Do I even want a user to be able to create multiple accounts?)
Easy for a potential attacker to guess (if they know the target's email address, they know the login id). (thanks Vasil)
Users may be tempted to use the same password they use for their email account, which is bad security. (thanks Thomas)
If you change email addresses frequently, it may be difficult to remember which address you used to sign up for a site after a long hiatus. (thanks Software Monkey)
A hacker could spam the registration form and use "email already taken" responses to generate a list of valid emails. (thanks David)
Not everyone has an email address. (thanks Nicholas)
If I went with email as id, I would provide a mechanism to allow it to be changed in the event a user changes address. In this case users would not be posting content to a public site, so a separate username won't be necessary to protect the email addresses (but it is something to consider for other sites).
Another option is to implement OpenID (which is a whole other debate).
This seems to work for Google, but their services are tightly integrated. What have I missed in my analysis? Do you have any recommendations? Does anyone have experiences to share?
FINAL EDIT
Thank you all for your responses. I have decided to use email as an id, but then allow the creation of a username for login purposes after registration. This allows a little flexibility while keeping registration as short as possible. It also prevents problems when a user changes email addresses (they can just log in with their username and update it). I will also be implementing methods to prevent brute-forcing of email addresses out of the registration and login systems (mainly a cool-down period after repeated attempts).
Personally, I prefer just using my email address as a username. It's one less thing to remember, and I never have to worry about my preferred name being already taken.
Just my 2 cents!
I think you missed a PRO:
Users are likely to remember their email address; and as email addresses are unique, they never have to worry about their preferred username being taken already.
As a user of websites, I can tell you that I hate memorizing unnecessary usernames. I don't use a unique handle or anything so I can never remember which variation of my name I used that wasn't already taken. I'd much rather type my email address.
Also, I like OpenID.
CONS
When the same password is used for the e-mail account, compromising the one automatically means compromising the other.
CON: Not everyone has an e-mail address. Consider if your database is ever accessed by an internal application. If you are running a store, people will call up and place an order by phone and refuse to provide an e-mail address. So while having an e-mail address as the default user ID is cool, be sure to allow alternates to get into the system. (Of course, this depends on the context.)
Learned this one the hard way.
I tend to not prefer pro/con lists, and instead try to think of benefits and challenges.
Challenge:
Some users will be tempted to use their email address from their ISP. Linking to an email alone, may be difficult for the users who forget to update their email in all the web sites they have signed up for before they change ISPs.
Instead:
You should consider allowing a user to provide multiple addresses, as well user-selected id and then let the user decide what they want they wish to do. Perhaps also consider allowing the user to provide an OpenID account.
CON: If I change my email address, suddenly all my account names are invalid. My name doesn't change, but my email often does. I have occasionally revisited a site after a number of years, and been stuck... what was my email address two years ago???
One setup you may want to consider: Have both a username and an email. The email is used to login and is always kept private, the username is used to identify the user in any public interaction, such as posting a comment. It winds up being slightly more secure as both halves of the user login credentials are kept private, whereas if you use a username for both login and public identification, half of the login is already known.
I definitely agree with you about having minimal registration for most cases, but depending on what you're doing you may want to balance that against added security for your users. Four fields isn't outrageous for registration, (username, email, password, confirm password), and if you're feeling particularly adventurous, you could cut it down to three by dropping the confirm password field, or two by emailing them a password that they can change later.
PRO
People hate having to create a unique name that fits their id and that has not already been taken to register for a site..So this is why the user id as EMAIL ADDRESS is so embraced.
ex:TStamper1930, who actually wants to remember 1930 at the end of my name that I really wanted
CON: If a hacker can try registering random email addresses en masse, he or she will be able to figure out which of those addresses are valid based on which registrations fail. This is a tactic that can be used to put together lists of known valid email addresses, which are a hot commodity on the spam black market.
Although now that I think about it, that's a problem that affects any website which asks for an email address as part of the registration process, regardless of whether or not there's a separate username. But it's still something to think about.
Stick to email addresses they are used everywhere, actually most of the major websites use them, they are unique so they save the user from struggling to find a name that's not used by others, also users won't forget their email addresses (in most cases at least :)), which is unlike usernames that they will keep on forgetting if they don't visit your site very often.
You shouldn't be worried about them being too long as all the major browsers (IE, FF .. etc) offer autocomplete to forms which is enabled by default, so you type the first letters in your email and you get a drop down list (ie. autocomplete list) where you just click to enter the whole email, personally I almost never type the email address in full, I always type the first letters then select the email from the autocomplete drop down list. Besides, if you allow users to be remembered (using a Remember Me checkbox and persistent cookies), it will be another reason to not worry about it.
I don't know about your app but usually users having multiple accounts is not desirable in most apps.
One con might be that if it's an email address the login can be guessed by people and brute force attacks attempted. Which is not really a big issue, since on most sites today the logins are publicly displayed.
The biggest pro is that logins are easier to remember this way.
A good setup is to require username and email. Allowing the user to login with either email address or username is very user friendly. An added benefit is the user can change their email address. It would also allow multiple accounts for one email.
To solve your con item of the email being too long to type in every time. I have implemented the StringScan Ruby library.
require 'strscan'
def signup!(user, &block)
self.email = user[:email] unless user[:email].blank?
str = StringScanner.new(self.email)
str.scan_until(/#/)
str.pre_match
self.login = str.pre_match
etc..
Then just change login method to allow either email or login to match password.
This works just like google or mobileme. A user can choose to just type in their email username (ie. username instead of username#gmail.com.)
I'm fighting with removing this right now. Here's a newer CON from the current era.
An email address is considered Personal Identifiable Information (PII) by many governments. Hence extra care needs to be taken any time you display it on a page, or even return it from an end-point.
Consider that many sites allow interactions between different users. This often means the site will provide a list of users to choose from (e.g. a drop-down list, or search results). This ca actually enable the leaking of PII by the site.
Usernames, on the other hand, can be completely anonymous. Given the prevalence today of password managers, users really don't need to actually remember their username and password.
If you don't care about forcing your users to login to your application with Facebook or some other social network (most people don't seem to care), then you can just use their social network email as their 'user id' when referencing other tables/documents (MySQL, Mongo, etc).
I've noticed the bonus to using social media logins is that all the security has been taken care of by said social network, including not allowing 2 users to have the same email or username in their database thus saving you the hassle of having to code for all of that. This is just my personal preference.