作者:高玉成 | 来源:互联网 | 2023-06-25 22:42
Onereallycommonpatternfoundinmobileapplicationsisadualemail+Facebookloginsystem.Facebookis
One really common pattern found in mobile applications is a dual email + Facebook log in system. Facebook is a very popular sign in method, but noteverybodyhas an account and not everybody wants to use their Facebook account to sign in to new services. This makes giving the option to users to use either email or their Facebook account to sign up very attractive.
There seems to be very little (that I could find at least) information out there on how to set up a log in / authentication system in Sencha Touch. So I’m writing a series of blog posts that will cover how to set up a log in system from scratch with the option to sign up with either email or a Facebook account. The application will have a PHP & MySQL backend and will also use PhoneGap Build.
Topics covered over the coming weeks will include:
- Setting up the database and API (this post)
- Creating the application and screens
- Email sign up system
- Authentication and generating sessions for users
- Auto login / remember me for return visits
- Integrating a Facebook signup system
In this first part, I will walk you through setting up your database and setting up some PHP files on your server that are ready to receive calls from your application.
Setting up the database
We’re going to have to create a MySQL database first of course so go ahead and do that, calling it whatever you wish. Once you’ve created the database, add the following table to it:
CREATE TABLE `users` (`id` INT(11) UNSIGNED NOT NULL AUTO_INCREMENT,`fbid` VARCHAR(255),`email` VARCHAR(100) NOT NULL,`password` VARCHAR(255) NOT NULL,`session` VARCHAR(255),PRIMARY KEY (`id`));
This will allow us to store the details the users uses to sign up, as well as any other details we would like to track. You could go ahead and add some other fields like ‘first_name’, ‘phone’ and so on if you wish. If you’re building out a real application, you’re likely going to require other tables as well, but this is all we need to actually get the log in system working.
Setting up the API
Throughout the log in and sign up processes, our application will be making calls to an API hosted on the Internet. This API will be created with PHP files which will interact with our database, and then return data in a JSON format to our application.
Although we are not implementing it just yet, our application will make calls to our server using an Ajax proxy. The problem with this is that we can run into some Cross Origin Resource Sharing errors来源gaodaimacom搞#^代%!码网 which might look something like the following:
XMLHttpRequest cannot load [URL]. No ‘Access-Control-Allow-Origin’ header is present on the requested resource. Origin ‘http://localhost’ is therefore not allowed access.
XMLHttpRequest cannot load [URL]. Origin [URL] is not allowed by Access-Control-Allow-Origin.
Request header field Content-Type is not allowed by Access-Control-Allow-Headers
Essentially, we’re running into security problems because we’re making requests to a domain different to the one the application is hosted on. I wrote a blog posts on this recently so if you’d like more information you cancheck it out here.
What we want to do now though is make sure we don’t run into any of these errors by making sure we set our headers (and everything else) correctly from the beginning. Now I need you to create a file called ‘users.php’ and add the following code to it:
What we are doing here is first connecting to the database – you will have to replace these details with your own. Next we are grabbing the ‘action’ which will be passed into the API through the URL. For example: http://www.example.com/api/users.php?action=something. Eventually we will cycle through this ‘action’ variable to perform the appropriate action. When we want to log a user in we could make an Ajax request to ‘users.php?action=login’ or if we wanted to log a user out ‘users.php?action=logout’ and so on.
Before outputting the result, we are also setting our headers here. These headers are necessary to overwrite the default Cross Origin Resource Sharing options and to prevent the errors above. If you read the CORS article I linked above you will notice that you can also set these headers at the server level instead of directly in your PHP files.
At the end of this file we are outputting ‘$result’. If you were to visit this page in your browser you would simply see ‘{‘success’:false}’. This is a JSON formatted string that is telling us that whatever operation was just performed on the server was not successful. In later parts of this tutorial series we will of course be outputting different data through this JSON string that will indicate whether a user successfully logged in, what their session key is and so on. This same format can be used to send in large, complex data including any and all details we had stored about a user in the database.
This concludes the first part of this tutorial series. At this point we have our database set up and our API ready to be added to and interacted with. Stay tuned for the following posts in this series; I’ll update with a link to Part 2 here when it is ready! Feel free to sign up to the fortnightly newsletter in the bar on the right for updates on any new blog posts.