Having googled various iterations and looked at the Facebook info I'm none the wiser.
What I'm looking to do is have the ability to cross reference my business page on Facebook and where a user has Liked our page they can then login to our app, thus if they unlike us their account is disabled?
Basically having written a free app that could be widely used for what our business provides we get a simplified marketing strategy.
The app I have is built around jQuery Mobile and links to a MySQL database.
Would the user register an account with me and then Like us on Facebook for us to cross reference the FaceBook API's? or would I have to have full FaceBook login? Or even worse is this not possible?
Related
I have a question regarding the login system. So let’s say that I’m building a website that requires from the users to login but I don’t want them to create an account only for my website. What I want to do instead is to log them in if they have an account to (let’s say ) the website X.
In short I want to use the login system of a second website X for users to enter my website. Is that possible in any way ?
You can use oauth if the website X implements it.
OAuth is an open standard for access delegation, commonly used as a way for Internet users to grant websites or applications access to their information on other websites but without giving them the passwords.
Facebook, google and others let you log in with their systems through oauth.
We have a media buy with Pandora. For mobile users,(once clicked on banner), they are directed to our site inside of the pandora app. There app does not accept GA cookies. Does anyone have any work arounds for tracking 3rd party in-app visitors? We are currently using UTM urls for inbound clicks, so we see initial "land", but nothing more than that.
We are considering creating a duplicate of our site and dedicate it to pandora visitors. This will give us aggregate numbers, but not sessions.
Thanks,
Udi
Mobile applications such as Pandora, Facebook, Twitter etc do not pass referrer information.
There are many articles around this if you search on Google, such as: http://searchengineland.com/rip-referrer-data-how-mobile-apps-can-kill-your-mobile-metrics-79982
All visitors from mobile applications will appear in the 'Direct' section of GA.
As you mention, the use of unique UTM click url will at the very least allow you to see where the user has come from.
Be aware of the discrepancies you will see between click 'redirects' from an accredited ad server such as DFP and GA 'visits' two very different methodologies.
I have a mobile application built with html 5. I've deployed the mobile application to iphone, android and blackberry using PhoneGap. The app loads up a list of user profiles via an Ajax call to my web server which has a database of user information.
My database of user information currently lacks user profile images for any of the users. How do I allow a user to associate their user profile on the mobile app with a profile image of themselves?
My current challenges are:
I can't seem to get html5 file upload button to work on the iPhone
a friend told me to try authenticating with linkedin, then ask for their linked in profile image. This can be done via of a concept of "childbrowser" on ios devices. But he claims there are some challenges (i think in terms of a good user experience) with android and blackberry?
Have you looked into Gravatar? Your users would have to set up their profile picture on the site, then they provide you a link to their chosen avatar from the Gravatar website. It doesn't require any authentication to use.
The iPhone browser lacks most of the file related APIs.
Anyway I have had enough problems with File APis to recommend the solution that #saluce is probably your best bet. Use a web service whenever possible to avoid having to deal with files as much as possible and for this particular use case, the gravatar solution is a good bet.
I'm trying to figure out the different skills and technologies necessary to develop webpage personalization apps that allow users to input and edit text/images/links on a webpage. About.me and Flavors.me would be the most advanced examples of what I'm talking about. Thanks in advance for any guidance.
#tim, they're database driven apps. The user enters information into a database (or Facebook profile, etc) and it's then pulled back out via a scripting language and presented on the page. The page layout is also stored in a DB and brought together with the user's profile information for what becomes the page layout you see. About.me seems to take it a step further by creating an email account that's tied to the user account.
Technology-wise, just about any back-end language could be used. Facebook is written in PHP, though they have a language-agnostic API that could be talked to from .net, java, php, etc. You'll need a database, and that probably would either be MySQL, Sql Server or Postgres, though there are certainly others. Finally you'd probably want to make use of the API's I spoke about including Facebook, Google, LinkedIn, etc. to aggregate information the user already has entered in different locations.
Examples of this type of site are varied and all over. Mint.com does it for financials. Grooveshark will tie into facebook and others to communicate and share your music collection. Linked in will tie into others as well. Integration is actually a very lucrative segment of the programming business right now. An app that talks to others has good marketable value.
Not sure if the title is quite right for the question but I can't think of any other way to put it..
Suppose you wanted to create multiple different web apps, but you wanted a user who was logged into one app to be able to go straight to your other app without re-logging in (assuming they have perms to look at the other app as well). If I'm not mistaken, if you're logged into gmail you can go straight to your iGoogle, googleReader, etc without re-logging in (if you set it up right).
How would you approach this? What would you use? Assume the apps already exist and you don't want to change the initial login page for the users.
What you're looking for is called Single Sign On. If you follow the link you'll find several implementations.
Open ID as others have mentioned is not such a scheme as it requires a seperate login for each site. Open ID is merely a shared authentication system.
You would issue a cookie against foo.com, which would then be visible on app1.foo.com, app2.foo.com.
Each application can then use the cookie to access a centralised authentication system.
Try CAS it should provide the features you are looking for.
What you want is a single sign-on (SSO).
There are two approaches to solving this problem:
Roll your own implementation. In its most trivial form it can be implemented by the first site setting a cookie that holds the ticket for the logged on user and the second site verifying that ticket and accepting the logged on user. There are quite a lot of potential pitfalls here:
you have to protect yourself against information disclosure - make sure that the ticket does not contain the actual user credentials
you have to protect yourself against spoofing - a man in the middle stealing a valid ticket and impersonating one of your users
and others
Adopt a third party SSO mechanism. Google, Microsoft, Facebook and other big companies allow integrating with their identity providers, so that your users could log on to their website and they handle verification, ticket issuing and so on. There's also OpenID, which is an open protocol you can use to enable SSO on your site through virtually any identity provider that supports OpenID. The potential drawback here is that somebody else controls your access to your user identity and can limit the features you can offer and data you can mine for your users.
As mentioned you can use something like OpenId or similar to make the process simple. Otherwise if you roll your own you could use a cookie to store the login, then basically ALL applications must have an entry point that mimics the base url.
Google for example uses mail.google.com to as a pipline into Gmail which allows it to read a cookie stored with the google.com domain.