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

[5.1] Distinction between real @parent and echoed content #10122

Merged
merged 3 commits into from
Sep 3, 2015
Merged

[5.1] Distinction between real @parent and echoed content #10122

merged 3 commits into from
Sep 3, 2015

Conversation

dmgawel
Copy link
Contributor

@dmgawel dmgawel commented Sep 1, 2015

This PR fixes security issue: @parent from view data was treated as real @parent.
This is an idea for non-breaking approach without restructuring everything. Needs review and tests.


Closes #10068.

@GrahamCampbell
Copy link
Member

Broken build.

@GrahamCampbell
Copy link
Member

Could you add tests that failed before and now pass please?

@dmgawel
Copy link
Contributor Author

dmgawel commented Sep 1, 2015

Yes, but not until tomorrow (UTC+2).

@dmgawel
Copy link
Contributor Author

dmgawel commented Sep 3, 2015

@GrahamCampbell ?

@@ -238,7 +238,8 @@ public function testSectionExtending()
{
$factory = $this->getFactory();
$factory->startSection('foo');
echo 'hi @parent';
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can you add another test that checks parent isn't converted anymore too please?

@GrahamCampbell
Copy link
Member

@taylorotwell I wonder if this change should be made on 5.2 and not 5.1, since it's a massive BC break, and the security implications are only minor.

@taylorotwell
Copy link
Member

What is the massive BC break?

@GrahamCampbell
Copy link
Member

People might be relying on the fact that the parent processing is done at the factory level, and not at the compiler level. That's quite a big change to make.

@taylorotwell
Copy link
Member

Can you give an example of how it would break an application?

@GrahamCampbell
Copy link
Member

{{ '@parent' }} - that used to work, now doesn't

taylorotwell added a commit that referenced this pull request Sep 3, 2015
[5.1] Distinction between real @parent and echoed content
@taylorotwell taylorotwell merged commit bdef7da into laravel:5.1 Sep 3, 2015
@taylorotwell
Copy link
Member

Thanks <3

@GrahamCampbell
Copy link
Member

Thank you very much @dmgawel. :)

@abhimanyu003
Copy link
Contributor

Thanks very much 👍

@franzliedke
Copy link
Contributor

Great job! 👏

@atmediauk
Copy link

Not sure if this is intentional and will stay like this but before if you had:

a layout file with
@yield('scripts')

a child file which extends layout with

@section('scripts')
@parent
<script>
    $(document).ready(function() {
     //foo
    });
</script>
@stop

and then the child above also had multiple @include at some point which had their own:

@section('scripts')
@parent
<script>
    $(document).ready(function() {
      //bar
    });
</script>
@stop

All the @Sections were passed along correctly but now the @section inside the @include is ignored.

I found this really helpful in scenarios where for example I had a media manager page. This media manager had multiple sections (tabs). One to upload, another to attach markup, another to embed etc. To help keep things manageable each tabs code and its related scripts section were in a separate @include file.

I think with this merge now all the scripts have to be bunched up in to the childs @section which isn't a big problem, but it previously sectioned off nicely :(

@taylorotwell
Copy link
Member

Can you give us the full views to try out?

On Friday, September 4, 2015, atmediauk notifications@github.com wrote:

Not sure if this is intentional and will stay like this but before if you
had:

a layout file with
@yield('scripts')

a child file which extends layout with

@section('scripts')
@parent

<script> $(document).ready(function() { //foo }); </script>

@Stop

and then the child above also had multiple @include
https://github.com/include at some point which had their own:

@section('scripts')
@parent

<script> $(document).ready(function() { //bar }); </script>

@Stop

All the @Sections https://github.com/sections were passed along
correctly but now the @section https://github.com/section inside the
@include https://github.com/include is ignored.

I found this really helpful in scenarios where for example I had a media
manager page. This media manager had multiple sections (tabs). One to
upload, another to attach markup, another to embed etc. To help keep things
manageable each tabs code and its related scripts section were in a
separate @include https://github.com/include file.

I think with this merge now all the scripts have to be bunched up in to
the childs @section https://github.com/section which isn't a big
problem, but it previously sectioned off nicely :(


Reply to this email directly or view it on GitHub
#10122 (comment).

@taylorotwell
Copy link
Member

This PR has been reverted due to multiple issues with existing applications. It can be attempted on 5.2. We also need to stop referring to it as a security issue since we have no known security exploit related to this bug.

@atmediauk
Copy link

Thanks for that Taylor, will put together a more complete example of what I meant.

https://gist.github.com/atmediauk/65e9bb437691c85a9560

In the gist above the @section('scripts') in upload-form.blade.php is no longer added.

Thanks again :)

@dmgawel dmgawel deleted the patch-blade-parent branch September 8, 2015 10:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants