4 ms·

Drupal uses it to implement templates. I always got the feeling that it's one of those language features where you want to take a deep breath before using it; s

Drupal uses it to implement templates. I always got the feeling that it's one of those language features where you want to take a deep breath before using it; sort of like when you type `rm -rf *` and haven't pressed enter yet.

derefr 12y ago
It makes perfect sense when PHP is actually being used as a backend-isolated, controlled-environment templating language. Imagine this setup: 1. you have Nginx at $DOMAIN, with your well-oiled API service (with no HTML rendering logic to be found within it) mounted to /, and a PHP FCGI instance sitting on /views. 2. Nginx is configured such that /views is only accessible from localhost. 3. Your webapp on / mostly sees requests with "Accept: application/json" or some such. It responds to these directly. 4. If your webapp sees "Accept: text/html", it does the same stuff it would to render a text/json response... but then takes that response body, and sends it in an HTTP subrequest back to Nginx, to, say, /views/accounts.php. 5. PHP does this: extract(json_decode($_POST['response'])); ...and then does whatever it does, simply and elegantly, to render your template. 6. Your webapp catches the response from Nginx, and sends it back without modification to the client.
- dsl 12y ago
  You are setting yourself up for a reflected request forgery attack.
- mtdewcmu 12y ago
  The way PHP allows fluid, dynamic interaction with the symbol table is pretty nifty, I think, and even if there were no extract() function built into the language, you could implement it yourself out of other primitives. I'm not one that believes that any feature of a language that can be used in dangerous ways should be eliminated (anything can be dangerous). I just think extract() is one that you ought to think carefully about before using. This example ought to reinforce that.

4 ms·

Drupal uses it to implement templates. I always got the feeling that it's one of those language features where you want to take a deep breath before using it; s

by mtdewcmu 12y ago

derefr 12y ago
It makes perfect sense when PHP is actually being used as a backend-isolated, controlled-environment templating language. Imagine this setup: 1. you have Nginx at $DOMAIN, with your well-oiled API service (with no HTML rendering logic to be found within it) mounted to /, and a PHP FCGI instance sitting on /views. 2. Nginx is configured such that /views is only accessible from localhost. 3. Your webapp on / mostly sees requests with "Accept: application/json" or some such. It responds to these directly. 4. If your webapp sees "Accept: text/html", it does the same stuff it would to render a text/json response... but then takes that response body, and sends it in an HTTP subrequest back to Nginx, to, say, /views/accounts.php. 5. PHP does this: extract(json_decode($_POST['response'])); ...and then does whatever it does, simply and elegantly, to render your template. 6. Your webapp catches the response from Nginx, and sends it back without modification to the client.
- dsl 12y ago
  You are setting yourself up for a reflected request forgery attack.
- mtdewcmu 12y ago
  The way PHP allows fluid, dynamic interaction with the symbol table is pretty nifty, I think, and even if there were no extract() function built into the language, you could implement it yourself out of other primitives. I'm not one that believes that any feature of a language that can be used in dangerous ways should be eliminated (anything can be dangerous). I just think extract() is one that you ought to think carefully about before using. This example ought to reinforce that.