Symfony2 Framework Combat Tutorial-fourth day: third-party login with Hwioauthbundle

In order to facilitate users to quickly publish content, we only use the third party request QQ login on the line.

If you intend to follow me to complete this project, may be because QQ needs to verify whether you have a personal domain name and stuck in this chapter, I wrote an article without OAuth. But this article is also best to look at, most of the knowledge points are exactly the same.

Using Hwioauthbundle for third-party logins

As you can imagine, a third-party login is a common requirement, and the relevant libraries are available. Here I would recommend one more: Hwioauthbundle

Like yesterday, we first introduced it through composer into our project:

12	$ composer require "hwi/oauth-bundle:0.4.* @dev"

and register it AppKernel in:

12345678910

//app/appkernel.phppublic function registerbundles() { $bundles = array(         // ... New HWI\Bundle\oauthbundle\hwioauthbundle(),     );}

Students who have used OAuth should know that a full OAuth client program will contain many links. Hwioauthbundle already have some well-written routes that we have introduced into the project:

123456789

# app/config/routing.ymlhwi_oauth_redirect: resource: "@HWIOAuthBundle/resources/config/routing/redirect.xml" prefix: /connect hwi_oauth_login: resource: "@HWIOAuthBundle/resources/config/routing/login.xml" prefix: /login

Bundles can have their own routing rules and corresponding controllers, which is one of the characteristics of the bundle.

Then according to Hwioauthbundle's documentation, we need to do some configuration:

12345

# app/config/config.yml hwi_oauth: firewall_name: secured_area

This configuration defines the addresses that need to be logged on with Hwioauthbundle before they can be accessed. But we can see there is no address in the configuration, there is only one firewall name, what is the matter? Let's not worry about it. Add Configuration:

12345678910

# app/config/security.ymlsecurity: Firewalls:         # ... secured_area: pattern: ^/ oauth: login_path: hwi_oauth_connect failure_path: hwi_oauth_connect

app/config/security.ymlis a file that is designed to configure user access rights. firewallsSeveral firewalls are defined in them. As you can see, the first firewall is the name of the firewall you just configured.

In the secured_area firewall, you can define the path that this firewall acts on. Because of the HWIOAuthBundle reason, the firewall can support the oauth configuration, which defines the login path login_path , the path of the login failure failure_path , their values are hwioauthbundle used to log on the route name. Here's a practical command to see which routes have been defined in the current project:

12	$ php app/console Debug:router

Finally, there is an oauth_user_provider option, for the moment we don't have to worry about it.

If you follow the steps to see here, you will find that firewalls other firewalls are also defined in the, dev demo_login demo_secure_area . Because Acmedemobundle has been deleted before the demo with the permission control and login form, so the definition of two demo_*** firewall, can now be safely deleted. Finally, there is a dev firewall, you can see that it defines a static file directory css|images|js can not be accessed through a firewall, and _(profiler|wdt) the two directories contain open tools access path, there is no need to be protected by firewalls.

There is also a need to pay attention to the order and finite level of firewall definitions: the higher the configuration location, the higher the priority, for example, when the user accesses a path/css/main.css, the first firewall configuration (although this configuration is actually used to shut down the firewall ...). ) has come into effect and will not be matched down.

Hwioauthbundle has helped us do a lot of work on the code, such as QQ's OAuth login address is what, parameter name is what ... All of these hwioauthbundle have been set up for us, and all we need to do is define an OAuth server and tell who the Hwioauthbundle account is (there is a hwioauthbundle currently supported OAuth server list), As well as setting Api_key and Api_secret:

123456789

# app/config/config.ymlhwi_oauth: resource_owners: # Owner's name can be taken casually, as long as the only name on the line QQ: type: qq client_id: <client_id> client_secret: <client_secret>

After defining the OAuth server, we then set the secured_area callback address on the OAuth server in the firewall:

123456789

# app/config/security.ymlsecurity: Firewalls:         # ... secured_area: oauth: resource_owners: QQ: check_qq

Note that the resource_owners in fact refers to Resource_owner callback path, the author can take a more accurate name.

Currently we have not defined check_qq a route named, and we hasten to add:

1234	# app/config/routing.yml check_qq: pattern: /login/check-qq

We can see that there is not one controller for a path, and what is this? I will only reveal through the event listener can be done, at present not much to say.

Let's go back to the security.yml file. Here is a brief talk about firewall's design ideas. Each of the firewall defines the following things:

1. Whether to turn firewall on or off, if it means that the security: false firewall is closed, such as a dev firewall
2. Which paths apply to this firewall rule, which pattern can be specified by reference to the dev configuration of the firewall
3. If the user is not logged in, how will they log in, such as a common way to use a login form, if you use this method, define what path the user will be directed to, and that path is used to check the user login information input. It is important to note that the path to the login page is not protected by a firewall (except in one case, after that), I will not say it, or it is very easy to think of.

There are a lot of other things to control the details of the behavior and technical details, and here is not much to say, when encountered will naturally say.

When the user is not logged in, the development toolbar will also have a display, easy to understand the current login status, not logged in when the following will be displayed

When accessing the path using a firewall, Symfony checks the visitor for a thing called Auth token, as if the eunuch in the martial arts film went into the palace, with the token proving his identity. To get a token, you have to log in to the login page to get it. The work of the firewall is also simple: with tokens, welcome! No tokens? Get out! Except, in one case, a firewall can set up a visitor who is not logged in, and each automatically issues an anonymous access to something called anonymous auth token. At this point, the user is not actually logged in, but is in the same state as the login. If this is a configuration, it is equal to the firewall is released, so there is a need to call access_control something to check each user is what kind of token, can do what kind of things.

Know the above concept, can say, do identity check can actually have two styles, the first style, do not login without tokens, configure the access path of the firewall, will not be publicly accessible to the "palace" directly separated from the wall; the second style, everyone can enter, through the control of the authority of the way to restrict the "certain identity of people "Behavior.

I personally prefer the first way. I like to let the firewall check the user "who you are", and let the access controller check the "What can you do" this clear division of labor, and, it is open area also need to create "token" Object for users I think it is a relatively wasteful practice. However, because hwioauthbundle in the login interface, you must check auth token (supposedly should first check if there is auth token, and then check the identity of Auth token), here we can only use the second way.

We will allow secured_area anonymous access (also called secured so good ...) ）

123456

# app/config/security.yml security: Firewalls: secured_area: anonymous: ~

Then set up in the Access_control, when creating news and changing the news, the requirements must be logged in:

12345

# app/config/security.ymlsecurity: access_control: - { path: ^/News/(new| (\d+\/edit), roles: is_authenticated _fully }

In this connection, our permissions-related configuration has been completed.

But it's still not over ... In the world of Symfony2, every login user who accesses the website needs a thing called user provider to generate, Userprovider in Symfony2 need to implement Userproviderinterface, We just need to implement this interface and return a Symfony2 user object on the line. But fortunately Hwioauthbundle has helped us achieve this interface, and has already defined the service for it, we can only use it:

123456789101112

# app/config/security.ymlsecurity: providers: oauth: ID: hwi_oauth. User. Provider Firewalls: secured_area: oauth: oauth_user_provider: service: hwi_oauth. User. Provider

Well, actually I don't know why I have to configure two times ...

Things have come to this point, not yet finished ... Well, it's actually over. Now we can access the /news path to see if it will automatically jump to the /login page, whether it will be logged from the QQ site and successfully return to the login user name:

As can be seen, although hwioauthbundle has such a problem, but have to admit that it has greatly improved the efficiency of development.

Finally, remember to delete the in_memory type of user provider for the test.

Symfony2 Framework Combat Tutorial-fourth day: third-party login with Hwioauthbundle