FUDforum
Fast Uncompromising Discussions. FUDforum will get your users talking.
Home » Imported messages » comp.lang.php » Sanitizing user input
Show: Today's Messages :: Polls :: Message Navigator
Return to the default flat view Create a new topic Submit Reply
Re: Sanitizing user input [message #169853 is a reply to message #169849] Tue, 28 September 2010 15:14 Go to previous messageGo to previous message
Jerry Stuckle is currently offline  Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma:
Senior Member
On 9/28/2010 9:14 AM, Web Dreamer wrote:
> Jerry Stuckle a écrit ce mardi 28 septembre 2010 13:21 dans
> <i7sjqg$jo5$1(at)news(dot)eternal-september(dot)org> :
>
>> Or, better yet, don't use a hosting company which has magic_quotes_gpc()
>> enabled, and you can forget all about this mess. The whole thing has
>> been deprecated and will be removed in PHP 6.0.
>
> Concerning the hosting company, you get the point.
> But sometimes we are asked do "develop" a web app to resell to another
> company, which uses an already-in-production server and for which they can't
> change the server settings without breaking an already-in-production-other-
> application on the same server.

And this code will then break when the host moves to PHP6 and functions
are removed.

Any host still running with magic_quotes enabled should be avoided at
all costs. If applications are dependent on it, they should be
rewritten now - before PHP6 comes out and you are forced to rewrite them
to get your site back up.

> By doing so, you ensure that your code is portable.
> The following ought also to always be included (with an include_once()
> directive):
> <?php
> ini_set('magic_quotes_runtime', 0);
> ini_set('magic_quotes_sybase', 0);
> ?>
>
> since 'magic_quotes_gpc' can't be changed at runtime, the previous I posted
> is still required.
>

Which will really screw things up, since some magic_quotes will be
enabled and others disabled.

> But I agree that for our own personnel server, It's indeed better to chose a
> proper hosting company. and that all the previous I have mentioned would be
> useless (and will be deprecated in PHP6)
>

And all new code should be written with this in mind.
>
> Oh, most important, if you are asked to develop on a server having other PHP
> apps, and that you use sessions, it is IMPORTANT tu use:
>
> ini_set('session.name', "SomethingElseThan_PHPSESSID");
>
> before using any "session_start()".
> This is because 'PHPSESSID' which is the default is probably used by another
> application on the same server, and there is a potential risk of mixing
> sessions...
> Once the user's browser has a session id for a session name, it will send
> the same to the same server even if they are two different applications, and
> you can have bad surprises.
> Imagine that in the $_SESSION array you store the grant level of a user
> (admin, user, etc). Imagine this user has a login for each of the web apps
> on the server, with the _same_ session.name but different grant levels,
> (user on app1, admin on app2), imagine the array key in $_SESSION has the
> same name for storing the grant permissions, if he logs in app1 first then
> in app2 after, he becomes admin on both... (depends on your code behind).
> Of course, this occurs only if they are on the _same_ server
> (https://myserver.org/app1/ and https://myserver.org/app2/ )
>
> Setting "ini_set('session.name', 'SomethingElseThan_PHPSESSID');" for each
> of your Web apps is a better guarantee to avoid any of such potential
> issues.
> But this is out of the current subject, just felt it ought to be mentioned.
>


Definitely NOT! This can really screw up other apps. For instance, the
site stores the login id in the session, with the default cookie
PHPSESSID. Now your page gets control and changes that session name.
It could easily screw up anything else which tries to get to the login id.

Much better is to coordinate the data - but that's only normal; when
working with an existing site, you need to have an understanding of what
the current code uses before going and adding new code. Otherwise you
can run into the exact problem you describe.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================

Report message to a moderator

[Message index]
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: how to write a wsdl for php webservice?
Next Topic: ANNOUNCE - NHI1 / PLMK / libmsgque - Work-Package-II
Goto Forum:
  

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ]

Current Time: Sat Nov 23 19:17:04 GMT 2024

Total time taken to generate the page: 0.04911 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.1.3.
Copyright ©2001-2023 FUDforum Bulletin Board Software