View previous topic :: View next topic |
Author |
Message |
Cloggs Smarty Rookie
Joined: 16 May 2003 Posts: 8 Location: United Kingdom
|
Posted: Fri May 16, 2003 3:19 pm Post subject: $smarty.session compiles as $GLOBALS['HTTP_SESSION_VARS'] |
|
|
Given the changes to PHP post 4.0.6 is it appropriate for the compiler in Smarty 2.5 .x to compile {$smarty.session.my} as $GLOBALS['HTTP_SESSION_VARS']['my'] ?
Should the new global variables not be used in stead and for the compiler to thus generate $_SESSION['my'].
Note that this issue is not just applicable to the session variables but also POST,GET,COOKIES,ENV and SERVER.
There may be an issue of backward compatability with installations using Smarty on older versions of PHP but nothing that can not be fixed with the use of php_version() in the compiler or some user switch in the Smartuy class. |
|
Back to top |
|
Wom.bat Smarty Pro
Joined: 24 Apr 2003 Posts: 107 Location: Munich, Germany
|
Posted: Fri May 16, 2003 6:21 pm Post subject: |
|
|
I have already suggested this once, as I always use these "new" superglobals and so cannot use the builtin smarty stuff, as these variables don't get updated if I change the $_* vars...
something like a switch would be nice...
I even offered to code it... |
|
Back to top |
|
boots Administrator
Joined: 16 Apr 2003 Posts: 5611 Location: Toronto, Canada
|
Posted: Fri May 16, 2003 7:17 pm Post subject: |
|
|
I'm guessing that the older forms are there for BC but I agree that newer platforms should enable the newer usage pattern.
If you are in a hacking mood, I believe in the recent CVS version of the code, the relevant section is contained in core.assign_smarty_interface.php. |
|
Back to top |
|
messju Administrator
Joined: 16 Apr 2003 Posts: 3336 Location: Oldenburg, Germany
|
Posted: Fri May 16, 2003 7:46 pm Post subject: |
|
|
i agree that time has come to support the auto-globals. what would you all prefer: a config-option (maybe $smarty->use_auto_globals , default false for BC) or should the php-version at compile-time decide which request-variable-scheme should be taken?? i'm pretty indifferent, whats better.
the former adds another option, that has to be documented and supported ofr indefinate future, the latter may break setups, where people already worked around this limitation. |
|
Back to top |
|
boots Administrator
Joined: 16 Apr 2003 Posts: 5611 Location: Toronto, Canada
|
Posted: Fri May 16, 2003 7:53 pm Post subject: |
|
|
I would take the latter approach, messju. I think the compiler is already making BC decisions in other areas and it doesn't make a whole lot of sense to make configurable those platform issues which are detectable. I'm not sure how it would break workarounds either.
+1 for compile-time platform decisions |
|
Back to top |
|
messju Administrator
Joined: 16 Apr 2003 Posts: 3336 Location: Oldenburg, Germany
|
Posted: Fri May 16, 2003 7:55 pm Post subject: |
|
|
umm, as a side-note: i just read the section on which this is posted. no, this is definately not a bug. it maybe an inconvinience for a lot of you, but this is not a bug, no way.
(btw: the keep-smarty-clean-and-mean-hardliners may consider it a bug, that you have access to the request-vars anyways ) |
|
Back to top |
|
boots Administrator
Joined: 16 Apr 2003 Posts: 5611 Location: Toronto, Canada
|
Posted: Fri May 16, 2003 8:43 pm Post subject: |
|
|
@messju: topic now living in feature requests. |
|
Back to top |
|
Wom.bat Smarty Pro
Joined: 24 Apr 2003 Posts: 107 Location: Munich, Germany
|
Posted: Fri May 16, 2003 10:12 pm Post subject: |
|
|
no, please no automatic decision at compile time
some reasons:
1) the production environment does likely differ from the development environment
2) maybe I use $GLOBALS["HTTP_*_VARS"] on machines which have PHP > 4.1.0 installed
3) ... err... well... I don't remember... *doh*
;>>>>>>
David |
|
Back to top |
|
boots Administrator
Joined: 16 Apr 2003 Posts: 5611 Location: Toronto, Canada
|
Posted: Fri May 16, 2003 11:23 pm Post subject: |
|
|
Quote: | 1) the production environment does likely differ from the development environment |
So? compilation is done in the target environment meaning that the "right" code is always generated.
Quote: | 2) maybe I use $GLOBALS["HTTP_*_VARS"] on machines which have PHP > 4.1.0 installed |
hmm. So that leaves the same predicament we have now but in reverse. The only problem really is when the global vars are updated via script--which I think is a funny thing to do anyhow. Never-the-less, the problem is that PHP is not communicating the structure changes automatically which I think it should. This is a tough one to get around.
AFAIK, HTTP_*_VARS are deprecated in PHP, so perhaps it should be a switch after all to allow for variant support. [@Wom.Bat -- Hey look, I capitulated! How about that! My monkey still needs spaces, though ]
To follow-up on messju's adamant response, my humble opinion is that this is NOT the type of thing that Smarty ought be doing anyhow. At least not automatically--it is not safe to simply have the supervars (in their entirety) imported into templates. I would much prefer a function (or API) that allowed me to control the Smarty assigned interface so that I can scrub the results or not have them assigned at all, at the application's discretion. After all, incoming data is the responsibliity of the application layer not the presentation layer
Should also make some templates that much faster
Last edited by boots on Sat May 17, 2003 10:53 pm; edited 1 time in total |
|
Back to top |
|
Wom.bat Smarty Pro
Joined: 24 Apr 2003 Posts: 107 Location: Munich, Germany
|
Posted: Sat May 17, 2003 12:50 am Post subject: |
|
|
... but maybe I want only compiled templates on the target machine
huh?
but currently, we have
$smarty.request.* => $GLOBALS["HTTP_REQUEST_VARS"]
$smarty.server.* => $GLOBALS["HTTP_SERVER_VARS"]
... etc
it would be nice to chose between the one above and this:
$smarty.request.* => $_REQUEST
$smarty.server.* => $_SERVER
... etc
IMHO, the only possibility to do it "right" is to have a switch which lets us choose between the new autoglobals ($_G/P/C/R/S/E) or the old globalized ones ($GLOBALS["HTTP_*_VARS"])...
maybe a programmer is using $GLOBALS["HTTP_REQUEST_VARS"] on php >= 4.1.0 and uses $smarty.request to access these...
if we do a compile-time check, it would automatically switch him to $_REQUEST, and his script wouldn't work anymore, as updated (that's the point) items in $_REQUEST weren't available in templates
@boots: goooood now try to make the monkey need bananas rather than spaces |
|
Back to top |
|
Cloggs Smarty Rookie
Joined: 16 May 2003 Posts: 8 Location: United Kingdom
|
Posted: Sat May 17, 2003 9:16 am Post subject: |
|
|
Whilst the discussion is moving on as to what and how to fix this in a future release we have resorted to a simple postfilter replacing GLOBALS['HTTP_SESSION_VARS'] with _SESSION. This is a compile time only sledgehammer but ultimate control of compile target version is at the user/designer level and outside the current version of Smarty.
Although in our case the design clearly separates business from display logic the business logic does use the storage (_tplvars) of Smarty to interface. Thus Smarty is initialised before the application logic manipulates some session variables (security, language, feature access) using the new style _SESSION. What we found is that these changes were not carried through to Smarty generated code which used HTTP_SESSION_VARS and thus not visible to Smarty. We decided to stick with up to date PHP standard and not revert our application code back to the Smarty older style.
Clearly there are significant design impacts on the variety of Smart implementations out there. A classical application provider version control issue.
My suggestion is to put out a clear statement that at a planned time in the future Smarty will use the new style super globals and for those who need old style to use a postfilter to revert it back. In short the opposite of what we do at present. |
|
Back to top |
|
messju Administrator
Joined: 16 Apr 2003 Posts: 3336 Location: Oldenburg, Germany
|
Posted: Sat May 17, 2003 9:51 am Post subject: |
|
|
@boots: i didn't want to sound adamant, i just wanted to throw in another opinion, that is not necessarily my own, but nontheless a valid one.
i also like the idea of abstracting this from the compiler a bit, but i think i have to ponder some things on this isssue.
it seems i don't get the point, why people don't want to go their own (application-specific) way on treating such a critical issue like request vars. for example one simple $smarty->assign_by_ref('session', $_SESSION) can save a lot of occurences of 'smarty.' in your templates, which are a little bit redundant anyway, aren't they?
another point: take a simple script: '{$smarty.get.foo}', turn off magic_quotes_gpc in your php.ini (which is a good thing in the first place) and voila: you successfully implemented a cross-site-scripting vulnerability waiting to be exploited.
so i don't see a lot of use in $smarty.[gpcs...] in spite of encouraging lazy design. assign_smarty_interface was a good thing before we had $_REQUEST, but it's unnessary now and went to a layer where it belongs (to php-request-handling) and out of smarty.
on the other hand, i can imagine (more or less nasty) applications for abstracting a little of the $smarty.[foo]-vars, maybe a more flexible request-vars handling would become a by-product, then.
i'll have a lookt into it.
greetings
messju |
|
Back to top |
|
gerard Smarty Regular
Joined: 18 Apr 2003 Posts: 84
|
Posted: Tue Jun 15, 2004 6:32 am Post subject: |
|
|
messju wrote: | another point: take a simple script: '{$smarty.get.foo}', turn off magic_quotes_gpc in your php.ini (which is a good thing in the first place) and voila: you successfully implemented a cross-site-scripting vulnerability waiting to be exploited.
greetings
messju |
Well, just use |escape if you display them, no? |
|
Back to top |
|
messju Administrator
Joined: 16 Apr 2003 Posts: 3336 Location: Oldenburg, Germany
|
Posted: Tue Jun 15, 2004 7:08 am Post subject: |
|
|
gerard wrote: | Well, just use |escape if you display them, no? |
absolutely correct. |
|
Back to top |
|
|