8000 [Routing] Generating URLs with host matching · Issue #6857 · symfony/symfony · GitHub
[go: up one dir, main page]
Skip to content

[Routing] Generating URLs with host matching #6857

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
zachbadgett opened this issue Jan 23, 2013 · 15 comments
Closed

[Routing] Generating URLs with host matching #6857

zachbadgett opened this issue Jan 23, 2013 · 15 comments
Labels
Enhancement Routing

Comments

@zachbadgett
Copy link
Contributor

Currently running into an issue with the new host matching when I'm trying to generate urls that requires me to pass in a host parameter.

InternalUserController:
    resource: "@ApiBundle/Controller/Internal/UserController.php"
    type: annotation
    host: "api.{domain}"

DashboardController:
    resource: "@DashboardBundle/Controller/DashboardController.php"
    type: annotation
    host: "{domain}"

The examples above work perfectly with the url matcher, but when needing to generate the url, it will require me to provide the domain parameter each time. I know this is how it's suppose to function, but it seems a bit annoying to require putting in the domain each time.
@stof stof mentioned this issue Jan 23, 2013
Closed
@Tobion
Copy link
Contributor
Tobion commented Jan 24, 2013

This is tricky. I agree it's not nice. Maybe there should be something similar to HttpKernel/Listener/LocaleLister that automatically adds the current host placeholders as default parameters. But the problem is:

  1. which are host placeholders/which path placeholders
  2. there can be multiple placeholders in the host
  3. the same name for a placeholder doesnt mean they have the same meaning (in contrast to the defined _locale placeholder), i.e. they can still have different requirements and meaning in the host pattern.
    E.g. host for route 1 is defined as: {subdomain}.{domain} but the host for route 2 is {subdomain}.{domain}.com.
    It would generate strange stuff using the parameters from route 1 for route 2.

@sstok
Copy link
Contributor
sstok commented Feb 18, 2013

As a workaround you can set a default that revers to a DIC parameter.
When actually needing it you can set it yourself as a parameter.

One thing that is a bug, is that when its set its used for path() which should only return a relative path not a full URL.

@Tobion Tobion mentioned this issue Mar 7, 2013
Closed
@Tobion Tobion mentioned this issue Mar 18, 2013
Closed
@Tobion Tobion mentioned this issue Apr 1, 2013
Closed
@alex88
Copy link
Contributor
alex88 commented Aug 5, 2013

No updates on this?

@alex88
Copy link
Contributor
alex88 commented Aug 5, 2013

@zachbadgett here I'm using

defaults: { subdomain: %subdomains_www%, domain: %site_domain% }

to define defaults for the routes

@brpaz
Copy link
brpaz commented Aug 7, 2013

Any news on this?
I have some routes with needed to be accessed only with a subdomain. (the typical use case mycompany.example.com). mycompny needs to be dynamic. The url matcher works, but twig path function complains with missing parameters.

As a workaround I have definied a subdomain listener which has a array of all paths that are protected by subdomain and then redirects to 404 myself if the user tries to access to a route without subdomain. This works but its not pretty. It would perfect to do this at Router level.

@sstok sstok mentioned this issue Aug 14, 2013
Closed
@sstok sstok mentioned this issue Sep 4, 2013
Merged
8 tasks
@tak-amboss tak-amboss mentioned this issue Oct 25, 2013
Closed
@Tobion Tobion mentioned this issue Oct 25, 2013
Closed
@stephanvierkant
Copy link
Contributor

Still no update here?

I'm trying to use multiple domains and subdomains for one website. I think something like this should work:

usa:
    host: "acme.com"
    resource: "@WebsiteBundle/Controller/"
    type:     annotation
    defaults:
        country: "en"

netherlands:
    host: "acme.nl"
    resource: "@WebsiteBundle/Controller/"
    type:     annotation
    defaults:
        country: "nl"

europe:
    host: "{country}.acme.eu"
    resource: "@WebsiteBundle/Controller/"
    type:     annotation

@toaotc
Copy link
toaotc commented Jun 8, 2015

here's the update: https://github.com/toaotc/ToaFrameworkExtraBundle.git

your configuration:

toa_framework_extra:
    request:
        recycle_attributes:
            - country

…so the country attribute in the request will be set to the router context.

This is heavily inspired by the LocaleListener.

@bonswouar
Copy link

Thanks for your little bundle @toaotc, that might be useful.

Though, there is no plan to include this kind of functionality in Symfony ?
I know this behavior is "normal" but it's not very user-friendly..

@bonswouar bonswouar mentioned this issue Jul 10, 2015
Closed
@Tetdoss
Copy link
Tetdoss commented Oct 11, 2015

You saved my life toatc ! Thanks for this bundle !

@alex88
Copy link
Contributor
alex88 commented Jan 8, 2016

It seems also not possible, with multiple host requirements for different urls, generate a url from a domain to the other http://stackoverflow.com/questions/34687016/symfony-2-generate-route-with-domain-restrictions-from-another-domain

@toaotc
Copy link
toaotc commented Jan 8, 2016

@alex88 i assume you use the toaotc/ToaFrameworkExtraBundle. the thing is that it recycles the subdomain from the request and so it overrides the defaults given in the route configuration. A quick win could be to use different parameter names like subdomain0 and subdomain1 f.e. in your route configurations to prevent the default override

@alex88
Copy link
Contributor
alex88 commented Jan 8, 2016

I'm not, anyway, just figured out my issue is something different, the firewall wasn't actually being correctly matched and so it was generating the url for another domain, sorry

@nicolas-grekas
Copy link
Member
nicolas-grekas commented Feb 23, 2018 •
edited
Loading

About i18n use cases, #26143 should do it
We could add a special _host placeholder for the api.{_host} use case during URL generation (and maybe also _domain and _tld?).
If someone would like to submit a PR, please do so we could have a discussion on actual code.
Otherwise, let's close, this issue is getting old.

@softrare softrare mentioned this issue Jul 26, 2019
Open
@noemi-salaun
Copy link
Contributor
noemi-salaun commented Jan 17, 2020 •
edited
Loading

The problem is that the Request::attributes property contain a little bit of everything (from URL fragment to security configuration). As a result, we cannot simply transmit everything from Request::attributes into the context of the UrlGenerator. I imagine that changing the way the attributes are filled will create too much breaking changes.

Naming convention

The simplest would be to pass only attributes which respect a certain naming convention. A listener like the one offered by toaotc/ToaFrameworkExtraBundle or inspired from the LocaleListener whould be easy to implements.

I tried to use some special char like api.{!domain} to express something like "here is my param !domain, I want you to keep it and forward it to the context of the request". But special char like that mess with the UrlMatcher.

'#^api\\.\\{\\!domain\\}$#sDi'

instead of

'#^api\\.(?P<domain>[^\\.]++)$#sDi'

when not using special char.

Default or new routing configuration

An other solution would be to define some sort of syntax to specify which fragment we want to keep. Something like :

web:
  resource: ../src/Controller/
  type: annotation
  host: api.{domain}
  defaults:
    domain: *

or

web:
  resource: ../src/Controller/
  type: annotation
  host: api.{domain}
  forwards:
    - domain

To express something like "I want you to use my current domain value as the default in the `UrlGenerator context"

If you want to go for this kind of solution, I would gladly submit a PR for it.

@chalasr
Copy link
Member
chalasr commented Dec 20, 2020

Let's close as per #6857 (comment). PR still welcome.

@chalasr chalasr closed this as completed Dec 20, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Enhancement Routing
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
0