Development

IRCLogs20110310-2 (diff)

You must first sign up to be able to contribute.

Changes between Version 3 and Version 4 of IRCLogs20110310-2

Show
Ignore:
Author:
lsmith (IP: 217.162.131.234)
Timestamp:
03/10/11 21:45:02 (7 years ago)
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • IRCLogs20110310-2

    v3 v4  
    1 = IRC logs of Part 2 = 
    2 {{{ 
    3 [1:40 PM] <kriswallsmith> so, johanness needs answers for subrequest security and eager response headers 
    4 [1:40 PM] <kriswallsmith> shall we discuss? 
    5 [1:40 PM] <naderman> johanness: around? 
    6 [1:42 PM] <naderman> for eager response headers I think the only question left is whether there should be a generic core.response listener which takes a response header bag from the request and turns it into headers or whether there should be individual listeners turning request attributes into headers 
    7 [1:42 PM] <kriswallsmith> still doesn't seem right to me 
    8 [1:42 PM] <naderman> the latter solution avoids setting response headers before you have a response and at the same time it will probably be more code 
    9 [1:43 PM] <kriswallsmith> the purpose of having it eager is so a controller can make changes 
    10 [1:43 PM] <kriswallsmith> otherwise core.response would be sufficient 
    11 [1:43 PM] <naderman> there is another reason 
    12 [1:43 PM] <naderman> if you have code that needs to run in core.request to provide your controller with information, and based on that same information you also want to set headers in core.response 
    13 [1:44 PM] <naderman> then to avoid code duplication you need to either set the response header in core.request or add the header in core.response based on that piece of information you added to the request for the controller in core.request 
    14 [1:44 PM] <kriswallsmith> you could stash on the listener 
    15 [1:45 PM] <kriswallsmith> but then the controller couldn't make changes 
    16 [1:45 PM] <naderman> yes 
    17 [1:45 PM] <kriswallsmith> so the only reason is so the controller can make changes 
    18 [1:45 PM] <johanness> kriswallsmith, what if your listener is not responsible for setting the headers? 
    19 [1:45 PM] <naderman> stashing on the listener however makes it difficult with subrequests 
    20 [1:45 PM] <kriswallsmith> naderman: the listener should be request scope 
    21 [1:45 PM] <naderman> kriswallsmith: right that works too 
    22 [1:46 PM] <naderman> kriswallsmith: the problem johanness has with this is that he does not want to have a separate listener to set the headers 
    23 [1:46 PM] <Stof> not for security listeners unless the whole security is request scope 
    24 [1:46 PM] <kriswallsmith> johanness: in that case it has nothing to do with this discussion, right? 
    25 [1:46 PM] <naderman> which I don't really understand 
    26 [1:46 PM] <johanness> kriswallsmith, no the listener is delegating to another service 
    27 [1:46 PM] <naderman> johanness: I don't understand that? 
    28 [1:46 PM] <kriswallsmith> and the other service sets headers? 
    29 [1:47 PM] <naderman> you mean the service decides what headers need to be set and what needs to be provided to the controller? 
    30 [1:47 PM] <johanness> kriswallsmith, yes exactly 
    31 [1:47 PM] <naderman> but why wouldn't the service just stash the info internally until you ask it for the headers? 
    32 [1:48 PM] <kriswallsmith> the delegated service could listen to core.response 
    33 [1:48 PM] <johanness> i think having a lazy response header bag on the request is not gonna hurt, and seems like a good compromise to me 
    34 [1:48 PM] <naderman> so you ask the service something on core.request which makes it respond and generate info for the header 
    35 [1:48 PM] <naderman> and on core.response you ask the service to add its headers to the response 
    36 [1:48 PM] <kriswallsmith> my concern is that we put it there and the only time it's used in for security 
    37 [1:48 PM] <kriswallsmith> *is 
    38 [1:49 PM] <naderman> a generic response header bag also has little use for overwriting by a controller because it'd have to parse the headers to figure out what to modify 
    39 [1:50 PM] <johanness> kriswallsmith, but most people won't care anyway, it's not like it's affecting their code immensely 
    40 [1:50 PM] <naderman> I think I agree with kris on this, either store info in the listener / in the service the listener delegates to, or if the controller needs to overwrite it, put it into a request attribute 
    41 [1:50 PM] <kriswallsmith> we'll still have to maintain it 
    42 [1:50 PM] <naderman> that way we stay true to the idea of creating a response only once 
    43 [1:50 PM] <kriswallsmith> it adds complexity 
    44 [1:51 PM] <johanness> complexity? 
    45 [1:51 PM] <naderman> kriswallsmith: I think it's simpler actually, just not as "clean" 
    46 [1:51 PM] <kriswallsmith> yeah, merging in those headeres 
    47 [1:51 PM] <johanness> kriswallsmith, it will only be merged if there is a header bag 
    48 [1:51 PM] <naderman> hmm right it's intransparent in a sense so I guess you could say it's complex 
    49 [1:51 PM] <johanness> since most people won't use it, it will not be there 
    50 [1:51 PM] <naderman> johanness: yes but what do you do if there is a Content-Type header in the header bag 
    51 [1:52 PM] <naderman> do you overwrite the one in the response already? 
    52 [1:52 PM] <naderman> do you keep the one already in the response? 
    53 [1:52 PM] <johanness> but at least there is an easy way to set header from anywhere 
    54 [1:52 PM] <naderman> you can't afterall just send both 
    55 [1:52 PM] <kriswallsmith> on the otherhand, set-cookie should be allowed multiple times... 
    56 [1:52 PM] <kriswallsmith> complexity 
    57 [1:52 PM] <naderman> yes 
    58 [1:52 PM] <johanness> the response has precendence obviously 
    59 [1:53 PM] <naderman> ok so for Content-Type the response has precedence, for Set-Cookie they are both added (unless the cookie name is the same?) 
    60 [1:53 PM] <naderman> this really does sound rather complex 
    61 [1:53 PM] <johanness> naderman, we already have such kind of logic atm 
    62 [1:53 PM] <johanness> like setting a content type if none is present 
    63 [1:54 PM] <kriswallsmith> yes, but that's specific to content type 
    64 [1:54 PM] <naderman> johanness: but we don't have generic header merging code 
    65 [1:54 PM] <johanness> and to charset 
    66 [1:54 PM] <naderman> I mean this code would have to be able to consider _all_ possible headers 
    67 [1:54 PM] <naderman> and deal with them appropriately 
    68 [1:54 PM] <johanness> naderman, they are key value paris 
    69 [1:54 PM] <naderman> I mean what do you even do with X- headers? 
    70 [1:54 PM] <johanness> it's not a big deal 
    71 [1:54 PM] <kriswallsmith> johanness: it's not that simple 
    72 [1:55 PM] <kriswallsmith> the same key can be used multiple times 
    73 [1:55 PM] <naderman> johanness: they are key value pairs, where some keys may occur multiple times, but not all 
    74 [1:55 PM] <johanness> so which can occur multiple times? 
    75 [1:55 PM] <kriswallsmith> i don't think we can abstract a mechanism for this 
    76 [1:55 PM] <naderman> and you have no way of knowing which ones may or may not be added multiple times 
    77 [1:55 PM] <kriswallsmith> Set-Cookie 
    78 [1:55 PM] <naderman> johanness: any header I make up myself starting with X- 
    79 [1:55 PM] <johanness> ok cookies is special we already cover that 
    80 [1:55 PM] <naderman> but only if I want it to 
    81 [1:56 PM] <johanness> naderman, can you elaborate? 
    82 [1:56 PM] <kriswallsmith> i think each feature that needs this will have to implement its own explicit logic 
    83 [1:56 PM] <naderman> johanness: you can have custom headers, whether or not those are allowed to be duplicate is up to you 
    84 [1:56 PM] <kriswallsmith> which is fine, since most people won't use it 
    85 [1:57 PM] <naderman> Via is another header which can occur multiple times 
    86 [1:57 PM] <naderman> Warning too 
    87 [1:57 PM] <johanness> kriswallsmith, so you ask me to implement magic in security instead of having it in the kernel? 
    88 [1:57 PM] <kriswallsmith> yes 
    89 [1:57 PM] <naderman> Link too 
    90 [1:57 PM] <naderman> etc. 
    91 [1:57 PM] <kriswallsmith> behind the interface of the security component 
    92 [1:57 PM] <johanness> i don't see how headers are the domain of security 
    93 [1:57 PM] <naderman> johanness: the security thing is not magic, it is limited to Set-Cookies in one particular case 
    94 [1:57 PM] <naderman> you do not need generic header setting in security 
    95 [1:58 PM] <Seldaek> ah crap irc meeting.. 
    96 [1:58 PM] <Seldaek> totally forgot 
    97 [1:58 PM] <kriswallsmith> Seldaek: this is part deux 
    98 [1:58 PM] <kriswallsmith> irc meeting reloaded 
    99 [1:58 PM] <naderman> <kriswallsmith> i think each feature that needs this will have to implement its own explicit logic <-- yes, best solution imho 
    100 [1:59 PM] <johanness> naderman, so we can have a early response cookies :) 
    101 [1:59 PM] <naderman> johanness: why do you keep insisting to make a generic solution for this, rather than solving the one problem at hand? 
    102 [1:59 PM] <johanness> because it's not easy to implement and the code gets quite ugly 
    103 [1:59 PM] <Stof> fabpot: here ? 
    104 [1:59 PM] <naderman> johanness: I disagree :D 
    105 [2:00 PM] <johanness> cookies should be fairly simple to implement and are the most common use case 
    106 [2:00 PM] <naderman> why don't you just set the cookies on core.response 
    107 [2:00 PM] <johanness> naderman, because of sub-requests etc. 
    108 [2:00 PM] <naderman> johanness: kriswallsmith already pointed out that the listner should have request scope 
    109 [2:00 PM] <naderman> so you don't need to worry about sub-requests 
    110 [2:01 PM] <kriswallsmith> johanness has pointed out that would add considerable overhead to security 
    111 [2:01 PM] <johanness> naderman, again that is not working for security 
    112 [2:01 PM] <naderman> well in that case use my solution? 
    113 [2:01 PM] <naderman> just stash listeners on sub-request core.request and unstash them on core.response? 
    114 [2:02 PM] <johanness> naderman, not trivial will make entire security even more complex 
    115 [2:02 PM] <naderman> you have that problem either way, even with "eager cookies" 
    116 [2:02 PM] <johanness> why? 
    117 [2:02 PM] <lsmith> johanness: tge question is in light of ESI .. how often will there really be subrequests for people that care about performance? 
    118 [2:02 PM] <kriswallsmith> you could either stash the response headers on the listener, organized by request using SplObjectStorage, or hijack a request attribute and stash the headers there 
    119 [2:02 PM] <naderman> johanness: where is the core.response listener that puts the cookies into the response? 
    120 [2:03 PM] <lsmith> so imho we should care about performance here so much 
    121 [2:03 PM] <naderman> lsmith: I do imagine they will be used a fair bit 
    122 [2:03 PM] <lsmith> the focus should be reliability and ease of maintenance 
    123 [2:03 PM] <naderman> lsmith: e.g. for the ajax-ability of requesting some sub-part? 
    124 [2:03 PM] <johanness> i mean i could implement a generic listener in the SecurityBundle which basically does that 
    125 [2:04 PM] <johanness> but i think it would better be placed in the ResponseListener 
    126 [2:04 PM] <lsmith> naderman: its easy to setup ESI and that is what people should go for .. at which point subrequests are turned into master requests 
    127 [2:04 PM] <naderman> right they will end up using AppCache anyway 
    128 [2:04 PM] <naderman> johanness: I think lukas is right, performance for sub-requests is not that important 
    129 [2:05 PM] <lsmith> meaning if we put a lot of effort into optimizing subrequests .. we are not benefiting ESI users 
    130 [2:05 PM] <johanness> another thing you should consider is how security integrates with other frameworks 
    131 [2:08 PM] <lsmith> johanness: which points to do see to consider there? 
    132 [2:09 PM] <naderman> I think other frameworks are all the more reason not to put something like a cookie stash into the framework 
    133 [2:09 PM] <naderman> because security would need to be able to deal with a framework that does not do that 
    134 [2:09 PM] <naderman> johanness: so I think that argument works against your solution ;-) 
    135 [2:09 PM] <johanness> naderman, not at all 
    136 [2:10 PM] <naderman> I mean having it inside security would work for other frameworks too 
    137 [2:10 PM] <johanness> naderman, but it is magically set on the response via stashing it in an splobjectstorage 
    138 [2:11 PM] <naderman> johanness: what? 
    139 [2:11 PM] <johanness> the contract of the interface is weakened 
    140 [2:11 PM] <naderman> I don't understand what you mean 
    141 [2:11 PM] <naderman> in which case is what stashed where? 
    142 [2:11 PM] <naderman> what solution are we talking about now? 
    143 [2:11 PM] <naderman> a cookie bag on the request in symfony2? 
    144 [2:11 PM] <naderman> or a cookie bag in the firewall? 
    145 [2:11 PM] <naderman> or no cookie bag at all? 
    146 [2:12 PM] <johanness> naderman, what solution are you talking about? :) 
    147 [2:12 PM] <naderman> johanness: the first one 
    148 [2:12 PM] <lsmith> i think at this point we have established that the remember me cookie needs to be checked at the start of the request 
    149 [2:12 PM] <lsmith> and that in the end something needs to be set on the reponse 
    150 [2:12 PM] <naderman> if you put the cookie bag into the symfony2 request class, then the security component will not work with a framework that cannot set cookies before it has a response 
    151 [2:13 PM] <lsmith> as such its clear we need to have some place to set something which will write into the reponse as soon as the reponse exists 
    152 [2:13 PM] <lsmith> agreed? 
    153 [2:13 PM] <naderman> yes 
    154 [2:13 PM] <naderman> the question is does it have to be a generic "write anything into request" or should there be a remember me cookie into response writer that is limited to this particular problem 
    155 [2:14 PM] <johanness> hm, ok we could have a general SecurityListener which only checks for one specific attribute 
    156 [2:15 PM] <johanness> that seems good, then i can still set it on the request but it would be no general set cookie feature 
    157 [2:15 PM] <naderman> yes 
    158 [2:15 PM] <naderman> that seems like a fair solution to me 
    159 [2:15 PM] <johanness> ofc if someone else uses that attribute it would be applied as well, but ok 
    160 [2:15 PM] <naderman> well make the name unique enough ;-) 
    161 [2:16 PM] <johanness> kriswallsmith, do you agree with this? 
    162 [2:16 PM] <naderman> although as per kriswallsmith, I'm not sure if a request attribute is necessarily the best place to store this 
    163 [2:16 PM] <kriswallsmith> using a request attribute? 
    164 [2:16 PM] <johanness> kriswallsmith, using a request attribute that only works for one specific cookie 
    165 [2:16 PM] <kriswallsmith> sounds good 
    166 [2:17 PM] <naderman> but it certainly solves the subrequest problem, so go for it 
    167 [2:24 PM] <beberlei> can someone point me to a good symfony introduction talk from one of the last conferences? 
    168 [2:24 PM] <beberlei> i need a starting point for my usergroup talk 
    169 [2:24 PM] <lsmith> beberlei: i used jordi last time 
    170 [2:24 PM] <lsmith> updated it last in early february IIRC 
    171 [2:24 PM] <lsmith> let me find it 
    172 [2:26 PM] <lsmith> beberlei: http://slides.seld.be/ 
    173 [2:27 PM] <lsmith> specifically http://slides.seld.be/?file=2011-02-01+Symfony2+Introduction.html#1 
    174 [2:27 PM] <beberlei> do you have the raw also? 
    175 [2:27 PM] <lsmith> this is raw 
    176 [2:27 PM] <lsmith> you need slippy from github 
    177 [2:27 PM] <lsmith> its plain html 
    178 [2:27 PM] <lsmith> you can modify as you wish 
    179 [2:27 PM] <beberlei> its html 
    180 [2:27 PM] <beberlei> not plain html 
    181 [2:28 PM] <lsmith> its easy to edit .. this is the entire point of slippy 
    182 [2:28 PM] <lsmith> slippy also supports to in the end inline all css/js/images to make self contained versions 
    183 [2:28 PM] <beberlei> but i still have to write the code in <pre> and escape it myself? 
    184 [2:28 PM] <beberlei> doesnt look very easy to me 
    185 [2:29 PM] <beberlei> i use slidedown, which is a jquery plugin + markdown for previous talks 
    186 [2:29 PM] <lsmith> seems easy to me .. but thats all i can offer :) 
    187 [2:30 PM] <beberlei> thanks :D 
    188 [2:33 PM] <henrikbjorn> lsmith: you are the one taling to Mathew ? :) 
    189 [2:34 PM] <lsmith> henrikbjorn: uhm .. about what? 
    190 [2:34 PM] <henrikbjorn> zend stuff.. cant find the post where the zend component dependency tool is listed 
    191 [2:34 PM] <lsmith> i contacted him about maing zend\log less painful to include in Symfony2 
    192 [2:35 PM] <lsmith> henrikbjorn: https://github.com/weierophinney/zf-examples/tree/master/zf-utils 
    193 [2:35 PM] <henrikbjorn> YEEEESSS 
    194 [2:35 PM] <henrikbjorn> i owe you :)!!!! 
    195 [2:36 PM] <lsmith> do i get one "shut up now, no questions anymore" ? :) 
    196 [2:36 PM] <henrikbjorn> yes :) 
    197 [2:37 PM] <lsmith> juchu! :) 
    198 [2:38 PM] <johanness> ok, we still need to talk about subrequest security; atm, we do not secure sub-requests in the sense that everything in the configuration (access_control) is not applied to sub requests 
    199 [2:38 PM] <johanness> this can get especially confusing if you secure your controllers by relying on the _controller attribute 
    200 [2:39 PM] <naderman> I think security should work the same for subrequests as for regular requests 
    201 [2:39 PM] <lsmith> johanness: imho we should secure subrequests, but we should not try to get fancy with performance optimization 
    202 [2:39 PM] <naderman> so that ESI/no-ESI makes no difference from a security perspective 
    203 [2:39 PM] <johanness> lsmith, moving everything to scope request is not solving our problem 
    204 [2:39 PM] <lsmith> now one thing where i keep getting mentally confused is how to handle if inner requests then fail because the user does not have sufficient access rights 
    205 [2:40 PM] <johanness> i'm infact very unsure if that would work at all 
    206 [2:40 PM] <lsmith> its easy if the subrequest is done inside a controller 
    207 [2:40 PM] <lsmith> but less so when done inside a template 
    208 [2:40 PM] <henrikbjorn> the on-error thing for include tag ? 
    209 [2:40 PM] <johanness> the handle() method has a catch parameter 
    210 [2:41 PM] <lsmith> henrikbjorn: yeah .. i guess really thats all thats needed 
    211 [2:41 PM] <lsmith> aka .. either turn the entire request into failed .. or just ignore and return empty content 
    212 [2:41 PM] <henrikbjorn> you would still get the error in a log, and through you notification system get notified 
    213 [2:41 PM] <naderman> lsmith: so in a template having an "else" tag for sub requests would be cool 
    214 [2:42 PM] <naderman> but I guess that's what you meant by on-error :) 
    215 [2:42 PM] <henrikbjorn> naderman: cant be done 
    216 [2:42 PM] <johanness> what happens atm if there is a 404 exception in a sub-request? 
    217 [2:42 PM] <henrikbjorn> well not like the for twig tag 
    218 [2:42 PM] <naderman> henrikbjorn: sure, why not? 
    219 [2:43 PM] <naderman> it requires more complex ESI code hmm 
    220 [2:43 PM] <henrikbjorn> because with ESI the content would be injected into it, it will not evalutate after the tag 
    221 [2:43 PM] <naderman> it works as long as it's not standalone 
    222 [2:43 PM] <henrikbjorn> yes :) 
    223 [2:43 PM] <henrikbjorn> but essentially thats what on-error does, render a template if this request is not successful 
    224 [2:43 PM] <lsmith> johanness: afaik you have the options i mentioned .. fail the current request or ignore the subrequest 
    225 [2:44 PM] <lsmith> uhm .. "Varnish only supports the src attribute for ESI tags (onerror and alt attributes are ignored)." 
    226 [2:44 PM] <lsmith> http://symfony.com/doc/2.0/cookbook/cache/varnish.html 
    227 [2:45 PM] <henrikbjorn> thats a bommer 
    228 [2:45 PM] <naderman> henrikbjorn: there is <esi:try><esi:attempt></esi:attempt><esi:except></esi:except></esi:try> for this ;-) 
    229 [2:45 PM] <henrikbjorn> wow 
    230 [2:45 PM] <lsmith> "ignore_errors: if set to true, an onerror attribute will be added to the ESI with a value of continue indicating that, in the event of a failure, the gateway cache will simply remove the ESI tag silently." 
    231 [2:45 PM] <naderman> but I doubt varnish implements any of those 
    232 [2:45 PM] <henrikbjorn> lets not support that 
    233 [2:45 PM] <lsmith> http://symfony.com/doc/2.0/book/http_cache.html 
    234 [2:46 PM] <Stof> lsmith: varnish does not support onerror 
    235 [2:46 PM] <lsmith> Stof: yeah .. thats a pretty big issue 
    236 [2:46 PM] <lsmith> so that means we need to make it possible for render tags to easily specify what they want to happen 
    237 [2:47 PM] <naderman> henrikbjorn: varnish argues that supporting stuff like ESI attempt/except makes no sense, because you can do the fallback inside VCL configuration 
    238 [2:47 PM] <naderman> same for onerror really 
    239 [2:48 PM] <lsmith> aka there needs to be a flag to catch the exception and instead return a Reponse with an empty content 
    240 [2:48 PM] <lsmith> standard > custom config 
    241 [2:49 PM] <lsmith> i knew it .. should have perstered that varnish guy some more 
    242 [2:49 PM] <lsmith> he brushed off my question with "such stuff isnt one size fits all" 
    243 [2:51 PM] <johanness> i think removing the ability to secure controller via configuration is probably the easiest solution 
    244 [2:52 PM] <lsmith> right .. it would at least prevent false expectations 
    245 [2:52 PM] <lsmith> but it would still lead to inconsistencies between ESI and non ESI 
    246 [2:52 PM] <johanness> hm, how do esi requests look like? what path do they have? 
    247 [2:53 PM] <johanness> maybe some special attribute? 
    248 [2:53 PM] <lsmith> johanness: they use an internal route .. so the path will look differently 
    249 [2:53 PM] <lsmith> hmm .. 
    250 [2:53 PM] <lsmith> so i guess there is no inconsistency in that case 
    251 [2:53 PM] <lsmith> since you would have to explicitly also secure the ESI paths 
    252 [2:54 PM] <lsmith> well it would still be inconsistent ... but less surprising 
    253 [3:00 PM] <johanness> fabpot, what is the status of https://github.com/symfony/symfony/pull/198 ? this is kind of blocking any changes to security atm 
    254 [3:08 PM] <beberlei> lsmith, which slideset had this architecture image how the MVC request stack worked? symfony from the trenches? 
    255 [3:08 PM] <lsmith> beberlei: yes 
    256 [3:08 PM] <lsmith> i can send you the source for that .. its a google docs 
    257 [3:09 PM] <beberlei> thad would be nice, kontakt@beberlei.de that is 
    258 [3:10 PM] <beberlei> hm no 
    259 [3:10 PM] <beberlei> thats not the one i meant 
    260 [3:10 PM] <beberlei> there was a nicer one somewhere else ;) 
    261 [3:10 PM] <fabpot> johanness: the problem with this PR is that there are many things in one PR 
    262 [3:11 PM] <fabpot> I can merge the protected/private changes 
    263 [3:11 PM] <lsmith> jonwage: i will upload a new copy of the trenches slides to slideshare ok? 
    264 [3:11 PM] <fabpot> but I want more time to think about the User/Account rename 
    265 [3:11 PM] <jonwage> ok cool 
    266 [3:20 PM] <fabpot> johanness: merged 
    267 }}}