All of my routes start with a /, maybe that is the problem.

Route::get("/admin" , array("before"=> "admin::auth" , function(){ ....... }));

Here is my auth filter setup and route as example. I just wrapped the routes in a group so as not to have to keep putting the filter in each of the admin routes.

Route::filter('admin-auth', function()
{ ... do auth stuff ... });

Route::group(array('prefix' => 'admin', 'before' => 'admin-auth'), function()
{ 
     // answers the /admin path
    Route::get('/', array('as' => 'admin-dashboard', 'uses' => 'Wpb\AdminModule\Controllers\IndexController@getIndex'));
});
  

Yeah. But i have all routes separated into different files and uses different filters. So i can't just wrap them with a global filter. Also i don't like to use different names like admin-auth, user-auth etc, which may sound weird, because admin::auth distincts and tells me that it is a filter in admin bundle. Admin-auth or user-auth or any other naming style is not clear where to look at unless you know the code.

SerdarSanri said:

Yeah. But i have all routes separated into different files and uses different filters. So i can't just wrap them with a global filter. Also i don't like to use different names like admin-auth, user-auth etc, which may sound weird, because admin::auth distincts and tells me that it is a filter in admin bundle. Admin-auth or user-auth or any other naming style is not clear where to look at unless you know the code.

My routes are not all in one file. It does not have to be a global group over all the routes, you can do groups anywhere with any number of routes, it gets a bit redundant if its only a couple but if you have five or ten then wrap it in a group attach the filter. Its mostly just a way to not have to repeat the duplicate stuff on each route.

If you want you can even set the filter to be with the controller class and not attach it to any route. Here is a example of that, http://laravel-recipes.com/recipes/41/registering-before-filte...

The naming convention and the location of the filters is totally up to you.

The code I posted was just to show an example that I had working, for you to compare with yours maybe something was slightly off (which is normally what happens) or to give you ideas it wasn't to make you do it that way or anything.

I actually like the idea with your filter naming convention admin::auth, as like you said it tells where the filter is. I'm likely going to update my code to use that style - so thanks.

I think I found the problem. I dig into Laravel package to see how it used to be and how it is now. In old system Route Filters were handled in /laravel/routing/filter.php file as below

/** * Call a filter or set of filters. * * @param array $collections * @param array $pass * @param bool $override * @return mixed */ public static function run($collections, $pass = array(), $override = false) { foreach ($collections as $collection) { foreach ($collection->filters as $filter) { list($filter, $parameters) = $collection->get($filter);

			// We will also go ahead and start the bundle for the developer. This allows
			// the developer to specify bundle filters on routes without starting the
			// bundle manually, and performance is improved by lazy-loading.
			Bundle::start(Bundle::name($filter));

			if ( ! isset(static::$filters[$filter])) continue;

			$callback = static::$filters[$filter];

			// Parameters may be passed into filters by specifying the list of parameters
			// as an array, or by registering a Closure which will return the array of
			// parameters. If parameters are present, we will merge them with the
			// parameters that were given to the method.
			$response = call_user_func_array($callback, array_merge($pass, $parameters));

			// "Before" filters may override the request cycle. For example, an auth
			// filter may redirect a user to a login view if they are not logged in.
			// Because of this, we will return the first filter response if
			// overriding is enabled for the filter collections
			if ( ! is_null($response) and $override)
			{
				return $response;
			}				
		}
	}
}

if filter doesn't belong to any bundle it was called as static function but if it does it was called with call_user_func_array to handle it inside the bundle. Which means we were able to define them like

 Route::filter("admin::auth" , function(){  ...... });

and also define parameters by

Route::get('panel', array('before' => 'role:admin', function(){   //    }));

but now with Laravel 4 we can still use parameters with same structure but somehow, not sure why, calling bundle style admin::filter functionality is removed. so in Route class it only checks if filter definition has "|" to split and ":" for parameters.

it is so odd because we can give a namespace for our package with

 $this->package("vendor/package" , "custom_name");

and we cann a view with

View::make("custom_name::view_name");

but we can not use same naming convention with filters.