Smarty Forum Index Smarty
WARNING: All discussion is moving to https://reddit.com/r/smarty, please go there! This forum will be closing soon.

$smarty.session compiles as $GLOBALS['HTTP_SESSION_VARS']

 
This forum is locked: you cannot post, reply to, or edit topics.   This topic is locked: you cannot edit posts or make replies.    Smarty Forum Index -> Feature Requests
View previous topic :: View next topic  
Author Message
Cloggs
Smarty Rookie


Joined: 16 May 2003
Posts: 8
Location: United Kingdom

PostPosted: Fri May 16, 2003 3:19 pm    Post subject: $smarty.session compiles as $GLOBALS['HTTP_SESSION_VARS'] Reply with quote

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
View user's profile Send private message
Wom.bat
Smarty Pro


Joined: 24 Apr 2003
Posts: 107
Location: Munich, Germany

PostPosted: Fri May 16, 2003 6:21 pm    Post subject: Reply with quote

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... Sad
I even offered to code it... Smile
Back to top
View user's profile Send private message
boots
Administrator


Joined: 16 Apr 2003
Posts: 5611
Location: Toronto, Canada

PostPosted: Fri May 16, 2003 7:17 pm    Post subject: Reply with quote

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
View user's profile Send private message
messju
Administrator


Joined: 16 Apr 2003
Posts: 3336
Location: Oldenburg, Germany

PostPosted: Fri May 16, 2003 7:46 pm    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail Visit poster's website
boots
Administrator


Joined: 16 Apr 2003
Posts: 5611
Location: Toronto, Canada

PostPosted: Fri May 16, 2003 7:53 pm    Post subject: Reply with quote

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
View user's profile Send private message
messju
Administrator


Joined: 16 Apr 2003
Posts: 3336
Location: Oldenburg, Germany

PostPosted: Fri May 16, 2003 7:55 pm    Post subject: Reply with quote

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 Very Happy )
Back to top
View user's profile Send private message Send e-mail Visit poster's website
boots
Administrator


Joined: 16 Apr 2003
Posts: 5611
Location: Toronto, Canada

PostPosted: Fri May 16, 2003 8:43 pm    Post subject: Reply with quote

@messju: topic now living in feature requests.
Back to top
View user's profile Send private message
Wom.bat
Smarty Pro


Joined: 24 Apr 2003
Posts: 107
Location: Munich, Germany

PostPosted: Fri May 16, 2003 10:12 pm    Post subject: Reply with quote

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
View user's profile Send private message
boots
Administrator


Joined: 16 Apr 2003
Posts: 5611
Location: Toronto, Canada

PostPosted: Fri May 16, 2003 11:23 pm    Post subject: Reply with quote

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 Wink ]

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 Wink

Should also make some templates that much faster Wink


Last edited by boots on Sat May 17, 2003 10:53 pm; edited 1 time in total
Back to top
View user's profile Send private message
Wom.bat
Smarty Pro


Joined: 24 Apr 2003
Posts: 107
Location: Munich, Germany

PostPosted: Sat May 17, 2003 12:50 am    Post subject: Reply with quote

... but maybe I want only compiled templates on the target machine Smile

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 Smile now try to make the monkey need bananas rather than spaces Wink
Back to top
View user's profile Send private message
Cloggs
Smarty Rookie


Joined: 16 May 2003
Posts: 8
Location: United Kingdom

PostPosted: Sat May 17, 2003 9:16 am    Post subject: Reply with quote

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
View user's profile Send private message
messju
Administrator


Joined: 16 Apr 2003
Posts: 3336
Location: Oldenburg, Germany

PostPosted: Sat May 17, 2003 9:51 am    Post subject: Reply with quote

@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? Wink

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
View user's profile Send private message Send e-mail Visit poster's website
gerard
Smarty Regular


Joined: 18 Apr 2003
Posts: 84

PostPosted: Tue Jun 15, 2004 6:32 am    Post subject: Reply with quote

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
View user's profile Send private message
messju
Administrator


Joined: 16 Apr 2003
Posts: 3336
Location: Oldenburg, Germany

PostPosted: Tue Jun 15, 2004 7:08 am    Post subject: Reply with quote

gerard wrote:
Well, just use |escape if you display them, no?


absolutely correct. Smile
Back to top
View user's profile Send private message Send e-mail Visit poster's website
Display posts from previous:   
This forum is locked: you cannot post, reply to, or edit topics.   This topic is locked: you cannot edit posts or make replies.    Smarty Forum Index -> Feature Requests All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group
Protected by Anti-Spam ACP