Archives for August, 2011

Defining multiple security rules in XML format for Symfony2

published on August 25, 2011.

This one falls into a category of bogus Symfony2 documentation. Or inconsistent behavior. Or whatever. It’s a bit frustrating.

I’ve chosen to use XML to define different settings across my sf2 apps: routing, ORM, services and of course security.

Symfony2’s security stuff let’s you define rules based on URL matching witch is, to some extent, explained in the documentation. The examples for YAML works fine, but for XML it’s kinda bogus.

The example says:

    <rule path="^/admin/users" role="ROLE_SUPER_ADMIN"></rule>
    <rule path="^/admin" role="ROLE_ADMIN"></rule>

which will actually die in a fire with an ugly as hell exception: InvalidConfigurationException: Unrecognized options “0, 1” under “security.access_control.rule". Thanks, that’s helpful. The funny thing is that if you have only one rule defined, it works!

After an hour of hunting up and down, I finally found the solution in the test fixtures of the SecurityBundle!

The solution is to omit the access-control tags:

<rule path="^/admin/users" role="ROLE_SUPER_ADMIN"></rule>
<rule path="^/admin" role="ROLE_ADMIN"></rule>

I thought about submitting an issue against the code, but as the fixtures use this format, I’ll open up a ticket against the docs. A real WTF moment.

Happy hackin’!

Update, August 26th, 2011:

Defining roles suffers from the same bug. So, instead of using:

    <role id="ROLE_ADMIN" >Admin</role>
    <role id="ROLE_SUPER_ADMIN">Super admin</role>


<role id="ROLE_ADMIN" >Admin</role>
<role id="ROLE_SUPER_ADMIN">Super admin</role>
Tags: rule, security, symfony2, xml.
Categories: Development, Programming.

Importing Symfony2 security settings from a bundle

published on August 25, 2011.

I started to work on/figuring out the security part in Symfony2 and one part where the docs fail so far is to explain how to import security settings from a bundle.

Once I put some thinking into it, it’s pretty easy actually. Simply import the needed security file in your main config file. Something like this will work:

# app/config/config.yml
    - { resource: parameters.ini }
    - { resource: '@AcmeDemoBundle/Resources/config/security.xml' }

where the security.xml file is the same as already described in the documentation.

Happy hackin’!

P.S.: Bonus tip: When googling for symfony2 stuff, start your query with +symfony2 to include only symfony2 results. Makes life a bit easier.

Debugging two PHP projects in Netbeans at the same time

published on August 19, 2011.

I’m currently working on some Symfony2 bundles and I have one Netbeans project for the main Symfony2 app and one project for the bundle. The bundle files are completely separated from the app and they are just linked (ln -s) together. It works great, except for the case when I need to debug some part of the bundle’s code with Netbeans + xdebug. The debugger starts for the “main” project, which is the Symfony2 app, but setting breakpoints with Netbeans (y’know, by clicking the line number) for the bundle doesn’t really work, as those are in the other project and not in the debugged one, rendering the whole debugging useless.

The solution is pretty easy actually: instead of setting breakpoints with Netbeans, use xdebug_break() where you want the break to happen and it will happily be caught by the IDE. After the break happened use the “Step into” (F7) functionality to see what’s going on.


published on August 11, 2011.


So, I got a haircut after 8 years.

This is the result. If you want, have a look at the whole album here: There, I fix’d it

I think it turned out pretty damn good.

Tags: about, random.
Categories: Blablabla.

Changing Jenkins' home directory on Ubuntu

published on August 04, 2011.

I’ve started to play around with Jenkins yesterday and I kinda don’t like that it’s default home directory is /var/lib/jenkins so I changed it to /home/jenkins, so I’m throwing the steps needed out here for future reference.

First, stop jenkins:

robert@odin:~$ sudo /etc/init.d/jenkins stop

Create the new home directory and move existing stuff from the old home to the new one:

robert@odin:~$ sudo usermod -m -d /home/jenkins jenkins

Now, I didn’t manage to set the ENV JENKINS_HOME to the new home, it was always using the old one, so I edited the init.d script:

robert@odin:~$ sudo vi /etc/init.d/jenkins

and in the “DAEMON_ARGS=…” line change JENKINS_HOME env to –env=JENKINS_HOME=/home/jenkins. In the end the whole line reads something like:

DAEMON_ARGS="--name=$NAME --inherit --env=JENKINS_HOME=/home/jenkins --output=$JENKINS_LOG --pidfile=$PIDFILE"

Update on September 20th: Vranac blogged about how to change the JENKINS_HOME properly

Start jenkins

robert@odin:~$ sudo /etc/init.d/jenkins start

and go to http://server:port/configure and verify that jenkins works as before and is using the new home.

Happy hackin’!

Tags: hack, jenkins, ubuntu.
Categories: Development, Software.
Robert Basic

Robert Basic

Software developer making web applications better.

Let's work together!

I would like to help you make your web application better.

Robert Basic © 2008 — 2020
Get the feed