Behat and “The current node list is empty.” error.

If your receiving the error “The current node list is empty” while using Behat, then likely your project is returning an HTTP 500 error. This may be because your bundle depends on some other bundle not available in your test environment. This was the case when for me when testing a bundle on travis-ci and i was not able to find documentation on this error.

One solution as suggested on github is to try dumping the contents of the scraper/browser to see what kind of error your getting.

     /**
     * @Then /^I dump the contents$/
     */
    public function iDumpTheContents()
    {
        print_r($this->getSession()->getPage()->getContent());
        //or print_r($this->getSession()->getDriver()->getContent());
        // The following produces "The current node list is empty."
        //print_r($this->getSession()->getDriver()->getText('//html'));
    }

/**

* @Then /^I dump the contents$/

public function iDumpTheContents()

{

print_r($this->getSession()->getPage()->getContent());

//or print_r($this->getSession()->getDriver()->getContent());

// The following produces "The current node list is empty."

//print_r($this->getSession()->getDriver()->getText('//html'));

}

However that will likely not give you any output if the server is returning an HTTP 500 internal server error. Your best bet is to just check your logs and do a search for any errors.

If your trying to run your functional tests on travis-ci then you might want to check out this great article on running Behat scenarios in isolation of your project.

Best of luck.

Git tagging.

Quick cheat sheet for referencing. Tags are a way to bookmark a particular version of your git repository for future referencing. Use them to bookmark stable and dev versions of your project.

$ git tag -l

1	$ git tag -l

$ git tag -a v1.1

1	$ git tag -a v1.1

$ git tag -a v1.0 <hash>

1	$ git tag -a v1.0 <hash>

$ git push --tags origin

1	$ git push --tags origin

Add a tag with inline message (no editor):

$ git tag -a v1.1 -m 'this is version 1.1'

1	$ git tag -a v1.1 -m 'this is version 1.1'

Remove a tag:

$ git tag -d v1.1

1	$ git tag -d v1.1

You can also push tags with a regular push with the tags argument:

$ git push -u origin master --tags

1	$ git push -u origin master --tags

Done!

Authorisation on Roles in Symfony2

Following a discussion on the IRC room from someone who viewed my post about login/logout handlers in SF2, i wanted to clarify that when dealing with Roles, they should be dealt with in the controller actions.

For off, you need to make sure you got the right hierarchy of roles. In your app/config/security.yml you need something following the structure of:

security:
    role_hierarchy:
        ROLE_USER:          ROLE_USER
        ROLE_MODERATOR:     [ROLE_USER]
        ROLE_ADMIN:         [ROLE_USER, ROLE_MODERATOR]
        ROLE_SUPER_ADMIN:   [ROLE_USER, ROLE_MODERATOR, ROLE_ADMIN]

security:

role_hierarchy:

ROLE_USER: ROLE_USER

ROLE_MODERATOR: [ROLE_USER]

ROLE_ADMIN: [ROLE_USER, ROLE_MODERATOR]

ROLE_SUPER_ADMIN: [ROLE_USER, ROLE_MODERATOR, ROLE_ADMIN]

Where the lowest level of access is at the top and the higher levels of access envelope the last levels of access.

Then you inside your controller actions you would do:

class fooController
{
	public function showAction()
	{
		if ( ! $this->container->get('security.context')->isGranted('ROLE_USER')) {
			throw new AccessDeniedException('You do not have permission to use this resource!');
		}
	}
}

class fooController

{

public function showAction()

{

if ( ! $this->container->get('security.context')->isGranted('ROLE_USER')) {

throw new AccessDeniedException('You do not have permission to use this resource!');

}

According the order of the role hierarchy if you have the role or higher than specified the controller action will continue, if you have a lower level of access than the minimum required then you will get an AccessDeniedException.

Redirecting on login/logout in Symfony2 using LoginHandlers.

Using login handlers or even logout handlers, we can do a number of last minute things before the user is redirected to where they need to go. Being able to intercept the redirect at the last minute and make the user get redirected elsewhere is relatively simple.

Firstly though, i notice a lot of people now who are using Symfony 2 are cheating somewhat by using an EventListener and registering it with the security.interactive_login event listener. This is not the best way to go about this, namely because this event listener is not intended for this purpose. Sometimes event listeners are not the best way to go because they were defined for a specific purpose other than your intention and using them may have undesirable side effects you may not notice right away. Using handlers however allows a little more flexibility in that in all likelihood regardless of changes to Symfony in future revisions, they should still work and were designed specifically for the purposes we will need them for.

Firstly, we need to define our services, personally, i am a fan of YAML, so i define my services as such but feel free to do the same in XML:

parameters:
    ccdn_user_security.component.authentication.handler.login_failure_handler.class: CCDNUser\SecurityBundle\Component\Authentication\Handler\LoginFailureHandler
    ccdn_user_security.component.authentication.handler.logout_success_handler.class: CCDNUser\SecurityBundle\Component\Authentication\Handler\LogoutSuccessHandler
    
services:
    ccdn_user_security.component.authentication.handler.login_failure_handler:
        class:  %ccdn_user_security.component.authentication.handler.login_failure_handler.class%
        arguments:  [@service_container, @router, @security.context]
        tags:
            - { name: 'monolog.logger', channel: 'security' } 
    ccdn_user_security.component.authentication.handler.logout_success_handler:
        class:  %ccdn_user_security.component.authentication.handler.logout_success_handler.class%
        arguments:  [@service_container, @router]
        tags:
            - { name: 'monolog.logger', channel: 'security' }

parameters:

ccdn_user_security.component.authentication.handler.login_failure_handler.class: CCDNUser\SecurityBundle\Component\Authentication\Handler\LoginFailureHandler

ccdn_user_security.component.authentication.handler.logout_success_handler.class: CCDNUser\SecurityBundle\Component\Authentication\Handler\LogoutSuccessHandler

services:

ccdn_user_security.component.authentication.handler.login_failure_handler:

class: %ccdn_user_security.component.authentication.handler.login_failure_handler.class%

arguments: [@service_container, @router, @security.context]

tags:

- { name: 'monolog.logger', channel: 'security' }

ccdn_user_security.component.authentication.handler.logout_success_handler:

class: %ccdn_user_security.component.authentication.handler.logout_success_handler.class%

arguments: [@service_container, @router]

tags:

- { name: 'monolog.logger', channel: 'security' }

Now our services are defined, we need to define the handlers themselves. I like to create a directory named Services in my user bundle for this purpose, then create 2 files. The first file is LoginSuccessHandler, the second is LogoutSuccessHandler. Our handlers will implement the appropriate interface for either our login or logout handlers, which require usually only one method in these instances.

Here is what the login handler should look like:

<?php

namespace CCDNUser\SecurityBundle\Component\Authentication\Handler;

use Symfony\Component\Security\Http\Authentication\AuthenticationSuccessHandlerInterface;
use Symfony\Component\Security\Core\Authentication\Token\TokenInterface;
use Symfony\Component\Security\Core\SecurityContext;
use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpFoundation\RedirectResponse;
use Symfony\Component\Routing\Router;

class LoginSuccessHandler implements AuthenticationSuccessHandlerInterface
{
	
	protected $router;
	protected $security;
	
	public function __construct(Router $router, SecurityContext $security)
	{
		$this->router = $router;
		$this->security = $security;
	}
	
	public function onAuthenticationSuccess(Request $request, TokenInterface $token)
	{
		
		if ($this->security->isGranted('ROLE_SUPER_ADMIN'))
		{
			$response = new RedirectResponse($this->router->generate('category_index'));			
		}
		elseif ($this->security->isGranted('ROLE_ADMIN'))
		{
			$response = new RedirectResponse($this->router->generate('category_index'));
		} 
		elseif ($this->security->isGranted('ROLE_USER'))
		{
			// redirect the user to where they were before the login process begun.
			$referer_url = $request->headers->get('referer');
						
			$response = new RedirectResponse($referer_url);
		}
			
		return $response;
	}
	
}

<?php

namespace CCDNUser\SecurityBundle\Component\Authentication\Handler;

use Symfony\Component\Security\Http\Authentication\AuthenticationSuccessHandlerInterface;

use Symfony\Component\Security\Core\Authentication\Token\TokenInterface;

use Symfony\Component\Security\Core\SecurityContext;

use Symfony\Component\HttpFoundation\Request;

use Symfony\Component\HttpFoundation\RedirectResponse;

use Symfony\Component\Routing\Router;

class LoginSuccessHandler implements AuthenticationSuccessHandlerInterface

{

protected $router;

protected $security;

public function __construct(Router $router, SecurityContext $security)

{

$this->router = $router;

$this->security = $security;

}

public function onAuthenticationSuccess(Request $request, TokenInterface $token)

{

if ($this->security->isGranted('ROLE_SUPER_ADMIN'))

{

$response = new RedirectResponse($this->router->generate('category_index'));

}

elseif ($this->security->isGranted('ROLE_ADMIN'))

{

$response = new RedirectResponse($this->router->generate('category_index'));

}

elseif ($this->security->isGranted('ROLE_USER'))

{

// redirect the user to where they were before the login process begun.

$referer_url = $request->headers->get('referer');

$response = new RedirectResponse($referer_url);

}

return $response;

}

Note my namespace is CCDNUser, and my bundle is called SecurityBundle, so our service is named ccdn_user_security.component.authentication.handler.login_failure_handler. Change this to your own namespace and bundle name accordingly but ensure to use the same format as used here, underscore your namespace and append the bundle name with an additional underscore without the term ‘bundle’ in it. Failure to get this part correct will mean your namespace will not be loaded and you will get problems later on in this tutorial as exceptions will be thrown regarding the service not existing.

Here is what the logout handler should look like:

<?php

namespace CCDNUser\SecurityBundle\Component\Authentication\Handler;

use Symfony\Component\Security\Http\Logout\LogoutSuccessHandlerInterface;
use Symfony\Component\Security\Core\Authentication\Token\TokenInterface;
use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpFoundation\RedirectResponse;
use Symfony\Bundle\FrameworkBundle\Routing\Router;

class LogoutSuccessHandler implements LogoutSuccessHandlerInterface
{
	
	protected $router;
	
	public function __construct(Router $router)
	{
		$this->router = $router;
	}
	
	public function onLogoutSuccess(Request $request)
	{
		// redirect the user to where they were before the login process begun.
		$referer_url = $request->headers->get('referer');
					
		$response = new RedirectResponse($referer_url);		
		return $response;
	}
	
}

<?php

namespace CCDNUser\SecurityBundle\Component\Authentication\Handler;

use Symfony\Component\Security\Http\Logout\LogoutSuccessHandlerInterface;

use Symfony\Component\Security\Core\Authentication\Token\TokenInterface;

use Symfony\Component\HttpFoundation\Request;

use Symfony\Component\HttpFoundation\RedirectResponse;

use Symfony\Bundle\FrameworkBundle\Routing\Router;

class LogoutSuccessHandler implements LogoutSuccessHandlerInterface

{

protected $router;

public function __construct(Router $router)

{

$this->router = $router;

}

public function onLogoutSuccess(Request $request)

{

// redirect the user to where they were before the login process begun.

$referer_url = $request->headers->get('referer');

$response = new RedirectResponse($referer_url);

return $response;

}

Our service definitions inject some of the classes we need to make use of our handlers, namely a Router object and the SecurityContext object, we can store these in member variables for later use. Then we wait for the onAuthenticationSuccess method to be called in our LoginSuccessHandler, once this has happened, we have a request and token interface object at our disposal. Using the security context object we can determine what role they have (i.e; ROLE_USER, ROLE_ADMIN etc) and appropriately redirect them as needed.

I like to redirect members of ROLE_USER role to where they came from prior to logging in. This is achieved by passing the ‘referer’ header into the redirect response object we return. I took this step both in the login and logout handlers.

Last thing we now need to do, is inform our security config that it needs to use these handlers by doing the following:

# App/config/security.yml
security:
    providers:
        fos_userbundle:
            id: fos_user.user_manager

    firewalls:
        main:
            #pattern:    .*
            form_login:
                provider:       fos_userbundle
                login_path:     /login
                use_forward:    false
                check_path:     /login_check
                success_handler: ccdn_user_security.component.authentication.handler.login_success_handler
                failure_path:   null
            logout:
                path:   /logout
                target: /
                success_handler: ccdn_user_security.component.authentication.handler.logout_success_handler
            anonymous:  true

# App/config/security.yml

security:

providers:

fos_userbundle:

id: fos_user.user_manager

firewalls:

main:

#pattern: .*

form_login:

provider: fos_userbundle

login_path: /login

use_forward: false

check_path: /login_check

success_handler: ccdn_user_security.component.authentication.handler.login_success_handler

failure_path: null

logout:

path: /logout

target: /

success_handler: ccdn_user_security.component.authentication.handler.logout_success_handler

anonymous: true

In this instance i am using FOSUserBundle and extending it in my own UserBundle, though this code is contained in the SecurityBundle. Which is probably the best way to do this. As the handlers used here work in any bundle because they plugin to Symfony2 core and implement their login handlers, and should not be dependant on any user bundle.

You can see a complete implementation of this in my security bundle found on github

Once this is implemented your on your way to a better login/logout system. Enjoy.

Symfony Embedded Forms ‘take 2′

Learnt some new things while working with symfony’s embedded forms, as we know, when they are have relations in the entities that the form is modelled after you want to ensure that when including the other form type that you create an instance of the formType representing the many in the manyToOne relationship. For example in the forum i am working on (which you can find on github here though currently still in development as of the date of this blog entry) a Topic has MANY Posts, as a result, we build our form by instantiating the PostType first and then adding the TopicType to it as a field because the PostType has a related Topic in the database schema.

But following up from the last post, what about when we have unique use cases for our form Types? What if we want to use a PostType without including the TopicType or we wish to conditionally decide wether for the purposes of editing we need to populate the form before presenting it?

To make this easier, in my FormHandlers what i choose to do is pass an array with some options we can use, namely a mode key specifies wether we are to ‘insert’ or ‘update’ an entity, and other keys for holding the entity to populate the form if mode is ‘update’

Here is an example from the top half of my TopicFormHandler:

class TopicFormHandler
{
	protected $factory;
	protected $request;
	protected $options;
	protected $form;

	public function __construct($factory, Request $request, array $options = null )
	{
		$this->factory = $factory;
		$this->request = $request;
		$this->options = $options;
		
		if ($this->options['mode'] == 'update')
		{
			$this->form = $factory->create(new PostType(), $this->options['post']);
			$this->form->add($factory->create(new TopicType(), $this->options['post']->getTopic()));
		}
		else
		{
			$this->form = $factory->create(new PostType());
			$this->form->add($factory->create(new TopicType()));
		}
	}
}

class TopicFormHandler

{

protected $factory;

protected $request;

protected $options;

protected $form;

public function __construct($factory, Request $request, array $options = null )

{

$this->factory = $factory;

$this->request = $request;

$this->options = $options;

if ($this->options['mode'] == 'update')

{

$this->form = $factory->create(new PostType(), $this->options['post']);

$this->form->add($factory->create(new TopicType(), $this->options['post']->getTopic()));

}

else

{

$this->form = $factory->create(new PostType());

$this->form->add($factory->create(new TopicType()));

}

To view the full source in greater context, explore the source on github here.

ANSI C Tutorial Ep.3 Parts 3 & 4.

ANSI C Tutorial Ep.3 (Part 3) Control Structures – Switch Statements

ANSI C Tutorial Ep.3 (Part 4) Control Structures – Nesting If statements and Switch Statements

ANSI C Tutorial Ep.3 Parts 1 & 2.

ANSI C Tutorial Ep.3 (Part 1) Control Structures – if statements

ANSI C Tutorial Ep.3 (Part 2) Control Structures – if statements continued

ANSI C Tutorial Ep.2 Part 1 & 2.

ANSI C Tutorial Ep.2 – (Part 1) Datatypes & Commenting code.

ANSI C Tutorial Ep.2 – (Part 2) Input Output to/from terminal.

ANSI C Tutorial Ep.1 Part 2 – Introduction

And part 2, to follow up to the previous video tutorial on programming in ANSI C.

Enjoy, if you found this helpful, and/or want more help; go to www.codeconsortium.com and join the community there.

ANSI C Tutorial Ep.1 Part 1 – Introduction

Upload 1 of a series of tutorials, for programming in ANSI C. A video by myself for youtube and as part of the www.codeconsortium.com community project.

M	T	W	T	F	S	S
« Aug
				1	2	3
4	5	6	7	8	9	10
11	12	13	14	15	16	17
18	19	20	21	22	23	24
25	26	27	28	29	30

Reece Fowells Blog

The home of a lot of crapola…

Tag: code