Skip to content
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.

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

$_format is lost on failure_forward #1879

Closed
mvrhov opened this issue Aug 1, 2011 · 7 comments
Closed

$_format is lost on failure_forward #1879

mvrhov opened this issue Aug 1, 2011 · 7 comments
Labels
Bug Good first issue Ideal for your first contribution! (some Symfony experience may be required) Security

Comments

@mvrhov
Copy link

mvrhov commented Aug 1, 2011

I've been debugging this for the past few days but to no avail.

This is the excerpt from my security file:

security:
    firewalls:
        default_json:
            poshtar_login:
                login_path: /login.json
                check_path: /login.json
                failure_forward: true
            context: store
            anonymous:  ~
            logout:     { path: /logout }
            pattern:    /.*
            provider:   poshtar

What I was able to figure out using a debugger is that the content type for subresponse? is set correctly to json, but sometime later, when responses get merged? and the request is asked again for a format the request returns html as the attributes bag is empty (controller resolver set the proper format in subrequest) so data sent to the browser has a wrong content type.

@vicb
Copy link
Contributor

vicb commented Mar 20, 2012

@mvrhov did #3564 fix your issue ?

@mvrhov
Copy link
Author

mvrhov commented Mar 20, 2012

Can you give me a couple of days to confirm. I have to update an app using ~one year old experimental forms branch, which is also using custom auth providers.

@mvrhov
Copy link
Author

mvrhov commented Apr 11, 2012

I still haven't had the time to fully update my code to be able confirm this.

@vicb
Copy link
Contributor

vicb commented Apr 13, 2012

Task for the BHD: check if this issue still exists in 2.0 / 2.1

@RGustBardon
Copy link

@vicb: aa53b88 (i.e. the #3564 fix) did not fix the issue, but 347053c did; therefore the issue exists in v2.0.15 but not in v2.1.0-BETA1. A test case is available at https://gist.github.com/3007325

@asm89
Copy link
Contributor

asm89 commented Jul 11, 2012

@vicb This issue is fixed then?

@fabpot
Copy link
Member

fabpot commented Jul 11, 2012

Closing this issue as it is fixed in master.

@fabpot fabpot closed this as completed Jul 11, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Good first issue Ideal for your first contribution! (some Symfony experience may be required) Security
Projects
None yet
Development

No branches or pull requests

5 participants