[Firewall] No routing and locale support

[adrianrudnik]

Simple use-case:

#app/config/routing.yml

languageselector:
    pattern:      /

frontpage:
    pattern:      /{_locale}
    requirements: { _locale: en|fr|de, _scheme: http }

and

#app/config/security.yml
    firewalls:
        public:
           ...
            form_login:
                check_path: ?
                login_path: ?
                default_target_path: ?
            logout:
                path: ?
                target: ?

The backrouting is very limited. Neither will work for the ? placeholder: /{_locale}, frontpage, /{_locale}/login.
I'm new to Symfony maybe im missing something but my general understanding from the docs was that routing is the main component that all other should rely on. This seems like a serious limitation for localized sites as I need to route the user through the languageselector route to get him back to the frontpage (or any localized page).

[Seldaek]

The "?" placeholder there is in fact regular expression paths, and not routing related. Therefore you should use something like: /[a-z]{2}/login for example, which should match /en/login and /de/login etc.

[stof]

@Seldaek the issue is that the login_path is used to redirect the user (as for default_target_path). It is not a regular expression

[adrianrudnik]

How can i determine if it should be en or de? I need to redirect the user to his "control panel" /{_locale}/account after a sucessfull login.

[Seldaek]

Ah sorry, I guess I misunderstood your question. This is indeed a problem for which there is no good solution atm I'm afraid. What you can try is this:

account:
    pattern:      /{_locale}/account
    defaults: { ... }

_post_login:
    pattern:      /account
    defaults: { _controller: FrameworkBundle:Redirect:redirect, route: 'account' }

That way if all goes well if you point the target_path to /account, it will redirect and use the session's locale to generate the url to /xx/account.

The other solution, that's maybe less hackish, would be to specify the "_target_path" (iirc) as a hidden form field in your login form, and generate the proper url based on the current locale.

[adrianrudnik]

Thanks for the workaround. I will try the redirection approach as it seems more controllable. Should i leave this open as a a feature request?

[Seldaek]

Make sure it works before thanking me ;) As for the feature, considering the configuration value is only a default and the actual value should be given in the form, I guess yes, if it's solved for you you can close this, and if you feel like being real nice you could head to https://github.com/symfony/symfony-docs and submit a pull request to improve the docs about this :)

[schmittjoh]

{_locale} can now be used as placeholder in the target path.

[Seldaek]

@schmittjoh looks like this code was never merged? Also I think you're misusing strtr() there, it should be strtr($this->determineTargetUrl($request), array('{_locale}', $session->getLocale())); or better just use str_replace in this case.