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 #169862 is a reply to message #169855] Tue, 28 September 2010 22:34 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 12:37 PM, Web Dreamer wrote:
> Jerry Stuckle a écrit ce mardi 28 septembre 2010 17:14 dans
> <i7t1fn$ckq$1(at)news(dot)eternal-september(dot)org> :
>
>>> 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.
>
> Yes, but as I mentioned, you are developing for something "already" hosted.
> you do not have the choice, it is imposed by your customer/employer.
> You are right, but I mention a precise case in which if you do not do it,
> there it breaks.
> What do you do in such condition?
>
>> Any host still running with magic_quotes enabled should be avoided at
>> all costs.
>
> I mentioned that you do not have the choice (imposed by employer/customer)
>
>> 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.
>
> If you include a file which does this, you only need to rewrite two/three
> lines in the corresponding file for the whole web site, not a big issue.
>
>>> 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.
>
> Nope, believe it, it "fixes" rather than screwing. It makes that you can
> work as if you had no more magic quotes at all.
>
>>> 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.
>
> It is important to keep in mind that a platform change (PHP 5 to PHP6) can
> be done by changing on, two or three lines in a unique file as I mentioned.
> By doing so, your code is compatible with an awfull server and ready to work
> on something proper.
>
>>> 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");
>>
>> 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.
>
> That's where you didn't understand what I mentioned. I was NOT talking about
> writing another page for a site!
> I was talking about writing a complete different application hosted on a
> same server. If you do not do what I do, then your app definitely screws the
> other one, believe me this is granted for sure!
> If you do as I do, the other app which does not invoke
> ini_set('session.name', 'SomethingElseThan_PHPSESSID');
> Will have session.name set to PHPSESSID and you screw nothing.
>
> I well mentioned "seperate apps" (on the same server) which have "no
> relation" and "should not interfere". It can be two vhosts i.e.
>
> In the case you mention, you are absolutely right, but I precised it was not
> this case of figure.
>
>> 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.
>
> You are right, but in my example I precisely mentioned that it is to do
> "another site" with "absolutely no relation to the current one" but "on the
> same server" and that they "should not interfere at all". I'm talking about
> the exact opposite! in the case you mention you are indeed absolutely right.
>

And how often does a company want something on their website which is
completely separate from the rest of the site? I've never seen that -
they all want it integrated into the rest of their site.

And if it's a different site, there is no clash with the session id, anyway.

--
==================
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 23:59:20 GMT 2024

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

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