I'm developing a client jabberd application for mobile(android) using (a)Smack.
Since, in my application, the users are registered by their phone numbers, the application should be able to recognize which contact has a jabber account on the server and suggest him/her for chatting.
After googlling the web I found that there is a jabber user directory (JUD) which I can use to check there is an account for a specific mobile number or not. (I'm using UserSearchManager).
My questions:
1- It seems that there is no record in JUD for a user who has not updated his vCard yet, so I cannot find him. Is there any solution to check the existence of this kind of users?
2- It seems that by using JUD, everyone outside of my application can fetch some important information of users such as mobile numbers, emails, etc. Is there any solution to limit JUD search engine? (for example, getting only "user field" as a input and returning only "full name field" of existing accounts or other useful limitation).
So by this way, I can recognize which person from the contact list has an account on the server and also other people cannot fetch important information of the exiting users.
Any command or advice is appreciated. Thank you.
I do not think it is possible as default, without customizing ejabberd application code.
Related
I'm developing my first iPhone app to make what is effectively an app version of a fantasy league I created for work colleagues.
I am using Parse for the backend of the app. I only want people to be able to register with their work email address ie only if their e-mail address is _#mycompany.com
I'm sure this would be quite easy to someone who knew what htey were doing but I'm kind of new to this so any advice would be much appreciated.
Thanks
You could do this in a number of ways. The easiest way would be to have the validation happen on-device - just check the e-mail address the user has put into the app, and only allow the registration to happen if it matches the domain you want to limit it to.
However, although this is very easy it's also open to abuse and it's not very flexible (if you want to add additional domains, you have to update the app).
Fortunately, Parse offers cloud code, which lets you validate data server-side. Cloud code is written in JavaScript, and you then upload it to Parse. There is full documentation on Parse's website, including examples for validating data.
I have built a Custom B2B app for one of our clients. My question is how to automate the distribution of the redemption codes.
I have already looked at some of the MDM providers. Their solutions are too expensive and all we really need is a way to distribute the app from a webserver, not manage a bunch of mobile devices.
As you probably already know, when a client buys a Custom B2B app through the Apple VPP program, they get a spreadsheet with valid redemption codes for the number of licenses they have built. This spreadsheet has 2 columns: 1) redemption code 2) URL to redeem the code
I want to provide my client with a URL where they can send their users to download the app. They just don't have the expertise/infrastructure to distribute the app themselves. And emailing clients is not going to work.
I'm not a web guy, but it seems to me that we could write a webpage that would look at the spreadsheet for the next available activation code and then redirect the user to the associated URL. I'm not concerned with the number of licenses they distribute since I have another way of auditing the real number of users (Flurry). So I want this to be as painless as possible.
In fact, I have multiple clients and want to provide them each with their own URL for their clients. It seems like this shouldn't be too difficult to code.
The problem is, I'm not the guy to write that code. Any ideas on how best to do this?
Assuming that you don't want to show the user a website you should be able to do this with an online service like parse.com and the features it offers.
From a user POV you would supply them with a link which directed them to parse.com with a path and parameters indicating the action to be taken (get app) and what account is associated. This would redirect the users browser to the appropriate destination.
The main issue (and this applies to any solution) is knowing if the user actually followed through and used the code. i.e. should it be removed from the DB so it isn't offered to another user in future. Then you would update the DB each time you get a new spreadsheet.
Anyway, this could be achieved with a little javascript in parse.com, specifically, by using cloud code which can interrogate and modify the DB and then redirect the user.
Obviously if you need user authentication of some kind or other restrictions then you would need to start adding some web interface on top of this in order to collect the details.
I have a project where I am using Selenium to test the Facebook auth. I created a Facebook app, created a test user inside this app and created some tests using Facebook login. Until now, it was working. But during the last two weeks something changed in Facebook and my tests are failing. It is due to interface changes in permissions dialog (I am targeting the button by his id). The second problem is that I don't get the email address from Facebook test user but a proxy email which is longer than 75 characters (my db field length is hardcoded in framework I am using).
If I log in as a regular user, it is working correctly and I get this permission box:
But when I log in as the test user I created (via 'switch to' in app's developer roles), I get this box:
I tested it ~2 weeks ago and this was yet working. Today it is changed. So my questions:
How to get back the old permissions box for test users?
How can I get the real email address and not the proxy?
Thanks!
I experienced the same problem with the Auth Dialog. I tried it with some old and new apps with various settings including March/Apr. 2013 Breaking Changes enabled/disabled, but it didn't help.
However, I guess I can help you with the email problem. When you login as a test user and go to account settings page, you will see the test user's primary email addres. By default this should be a really long one like the image I attached.
Facebook Platform returns this primary email address. If you pass the Auth Dialog with your test user account and see the privacy setting page, you will find the default primary email address is shared with the app. You have to provide a new email address for the test user and set the new one as primary email address via account setting page.
Why is the Login Dialog different with a test user?
With your test user, you can see the future of login dialogs. In fact, this isn't "not working" but this is an update which was unveiled on December 2012. Let me quote:
Our Login dialogs have undergone a redesign to make it easier to
understand permissions that apps request. We've simplified
presentation and have also updated our language for greater clarity.
“Basic info” has been renamed to “public profile and friend list,” to
reflect what what is being shared. Apps accessing your public profile
get your name, profile picture, age range, gender, language, country
and other public information.
Source: Providing People Greater Clarity and Control, developers.facebook.com/blog
The reason why you don't meet this update with a regular user, is that Facebook doesn't use to update everyone at the same time. They partially launch updates depending on the country, the type of account or some other parameters I ignore.
Example of a partial update (unified_message FQL table) dedicated to developer accounts:
We are providing early access to this API for registered developer
accounts only until the new messaging system is broadly available. You
should use the message table for production applications at the
current time.
In our case, we now know that test users can access to the update, but it is also said:
We have already launched many of these improvements as part of our
iOS6 integration and are now rolling them out more broadly.
About proxy emails
In fact, proxy emails are a way for any users to keep their real email anonymous. You have to consider proxy emails.
When joining an app, the user can choose between a real email and a proxy email:
Other thing you need to expect are users who didn't validate their account when connecting to your app, a case which is possible as described here and here.
Then, why do test users give back a proxy email? Because test users (being bots and having fake emails) didn't validate their emails.
You see that in at least 3 cases (and finally, test users are a good example), you need to handle these proxy emails. They are incidentally or accidentally met by developers and they can't be neglected. For your case, you can still try to disallow tests users who have a proxy email from accessing your app. But you should accept them and shouldn't force them to share their original e-mail addresses. A better solution is that you validate the test users emails:
Connect to the test user account that gives a proxy email
Add an email address (password needed here),
Go to the email mailbox and click on the validation link,
Set the new email address as primary,
The test user should now give his original email and not a proxy anymore!
So there are definitely many tutorials out there regarding how to integrate various individual social network authentication/registration into existing user accounts. But the scenario I can't seem to find out much information about is if a user signs into your account with different social network credentials. For example:
Scenario #1
User registers on site using site's authentication.
User then signs in/registers on site using Facebook Connect.
User then signs in/registers on site using Twitter.
How do I integrate all of these into one account?
Obviously once a user is registered, they can add other social network associations in the account settings pages. But I am more concerned if they register via the other social network not remembering they are already setup.
My general thoughts are trying to figure out a way to use the "username" or email to try and guess and present the user a way to combine accounts right there.
Anyone have any thoughts?
following up -
if your users can't remember that they've signed up previously, well, best of luck to them in general ;)
much as you described, i'm planning on giving users the option to link additional accounts once they have signed in by one means or another.
but as far as cross-checking, there's only so much you can do. many social network APIs do indeed provide email addresses (once you've busted in through OAuth) but these may be accessible only if a user has elected to make his/her address public, which is not guaranteed.
also not guaranteed is that the user used the SAME email address for each social network account, so even if you manage to retrieve an address it may or not be of any use to you.
finally, if you find matching email addresses via such means, it might be advisable to prompt the user to link accounts rather than assume he/she wants this done automatically. some people like to maintain multiple personalities. i.e. "it looks like you are also signed up with twitter - do you want to link your accounts? it will make your life seem worth living."
you might consider offering incentives to link user accounts or to provide an email address (up to you of course to figure out what these might be, based on the functionality of your website).
solution i am working on, database-side, is to maintain multiple accounts and then if link information is discovered by various means, said link is indicated in a lookup table.
an alternative is once you find a link, attempt to combine all relevant entries for the multiple accounts into one account entity - all i can say about this latter approach is that i would do so with caution as there could be a formidable level of complexity depending on the user's activity level and the complexity of your database schema.
in my (mental/actual) namespace a user who registers the old-fashioned way has a 'standard' account and one who uses a social network has an 'alias' account. then the goal becomes to define where the alias is supposed to point, i.e. create the lookup such that a subsequent login via either means retrieves the relevant information for both accounts (with a preference for displaying personal data for the 'standard' account).
btw i figured out how to make twitter OAuth behave since my last post - you can look at my other answers for details if you're interested.
JB
hi matt,
i'm working on the same problem right
now.
assuming the user starts with regular
site account (which is not
necessarily safe to assume if he sees
all the pretty "connect with XXX
network" buttons!!!), you can use
either OAuth or the javascript APIs
(facebookConnect or #anywhere -
haven't fully figured out the latter
yet and i'm not sure I recommend it as
I don't think it provides as rich an
API as do the backend libraries) to
login to the other sites.
the APIs should return certain
information after a successful
login/redirect from the social network
- such as the user ID and an ACCESS TOKEN which you can then store in your
database in some capacity associating
your 'actual' application user with
the ID of the social network.
when the user returns to the site, you
can then
1 verify cookies set by the social
network services (various schemes
typically verifying a signature, based
on sha1 or md5 hash of your
application data - by which i mean the
data you get when you register your
app with twitter/facebook, typically a
consumer key, application ID, etc. -
with the received cookies) so you know
the user has logged in with the social
network
2 find your database entry association
as described above
3 login your user manually based on
the assumption that facebook/twitter
connection is secure.
caveat: this is only as secure as your
implementation (or as secure as
facebook/twitter's implementations, if
you prefer...)
although twitter's OAuth does not
currently seem to work quite right,
their general description of the
process is pretty informative:
http://dev.twitter.com/pages/auth
good luck.
J
I have been contemplating adding FB auth to our app, but we know that our returning users might click it and complete checkout for a new item, and then be surprised to not see any of their existing orders. To solve this, when a user clicks the 'Login with Facebook' item, we are using that click to fire a dropdown menu with two options:
[ Login with Facebook ]
[ Create new account ]
[ I have an account ]
If the user clicks 'I have an account' we send them to FB auth and return email from FB to our app. We compare that email to our existing users. If we match, we add the FB creds to the user. If no match, we throw an alert:
The email you have with FB does not match any of our accounts. To log in to your existing account, login with your email below, or update the email in your Facebook account
This allows the user to create a whole new account, if they want to keep them separate, without needing a new email service. While this is an edge case, it is a feature.
I hope this is allowed but I have a number of questions regarding Facebook Connect, I'm quite unsure on how I should approach implementing it.
I am working on a live music type service and currently have user registration, etc. If I were to implement Facebook Connect alongside this, would I still be able to email the Facebook Connect users as if they were on my database?
Also, would it instead be possible to let users who have Facebook "link" their accounts once registered so I am able to give them the benefits of sharing via Facebook and inviting friends while still having an actual registered user on my system.
I have tried to read up answers to the above questions but what I've found is quite ambiguous.
Thanks, look forward to your views.
Facebook's documentation process is very poor, so don't feel bad about having a hard time getting started. Their wiki-style approach to documentation without any real official documents tends to leave the "process flow" tough to grasp, and requires piecing together parts of a bunch of randomly scattered docs.
Facebook has an obligation to protect privacy, so they never make a user's actual email address available to application developers, through Connect or normal applications. They do have a proxied email system in place that you can use, however, you must get explicit permission from a user in order to email them. There's a decent document on proxied email here. You can get permission by prompting for it; there's several methods for doing so linked in that document.
In regards to linking Facebook and local accounts, this would definitely be the way to go. Once a Connect user logs in, you want to store that fact for that user so you can provide the Facebook-specific functionality. I would simply create a normal user account in the database for every new Connect user that came by, with it's own local id, so that you don't have to do special handling of two different types of user accounts all over the site. That being said, the account would obviously have to be marked as a Facebook user's account (I use an externalId column in my users table), and any part of the site that relied on information you might otherwise have locally would have to handle the Facebook aspect properly (such as using proxied email instead of normal email).
For existing users, you could arrange an "account link" by having a process whereby they log into FB Connect after they've logged into the site already, and you could detect that and simply add their FB id to your users table. After that, they could log in through Connect in the future, or through your normal process. I've never done this, but it should be possible.
If you write the account handling code generically enough, your site will be able to function well no matter what kind of user you throw at it.