FUDforum: comp.lang.php » Sanitizing user input

Home » Imported messages » comp.lang.php » Sanitizing user input

Show: Today's Messages :: Polls :: Message Navigator

Re: Sanitizing user input [message #169929 is a reply to message #169917]

Thu, 30 September 2010 12:32

Jerry Stuckle
Messages: 2598
Registered: September 2010

Karma:

Senior Member

On 9/30/2010 3:44 AM, Web Dreamer wrote:
> Le 29/09/10 18:21, Jerry Stuckle a écrit :
>> You have inconsistency because a person has to use multiple logins to
>> the same site to access different information. It means users not only
>> have to keep track of multiple userids/passwords for the same site, but
>> which userid/password accesses which information.
>
> You can have identical logins (same database) with different session
> handling.
> And it works very neatly :-)
> Why do you think it mean having different logins?
> I want to have a session to not log automatically to the other for
> security reasons.
>

Which would be a huge security exposure. Any decent security expert
will tell you to have different login ids/passwords for different jobs.

But if you have the different applications on different virtual hosts,
you don't need to change the session id.

>>> I was only mentioning session handling.
>>>
>>
>> Which affects consistency.
>
> No
>

Yes it does. You now have completely separate applications on the same
site. Either there is no link between them, which means users have to
type in a page, or you have links between them and now have to worry
about which session id is being used.

>>> A shopkeeper can have two companies:
>>> A shoe shop
>>> A flower shop
>>> two different entities.
>>> They share one same server (same boss, different legal entities, and
>>> employees).
>>> You SURELY do not want to mix anything together! But the owner of the
>>> shops
>>> can afford only one server (2 or 3 employees in each shop), and you
>>> configure vhosts on the server.
>>>
>>
>> No, and I would have two separate sites - one for each company. No
>> special session handling required, because each site can only access its
>> own cookies - and therefore only its own session information.
>
> The shopkeeper wants the same domain name "HisSurname.com/shopname"
> That's "his" choice, I have do with this. Or he get's someone else.
>

You are just being argumentative now. First of all, if the businessman
has two different businesses, they are going to have two different
names. That's just simple marketing. The same goes for web sites. He
wouldn't want someone looking for flowers to land on a shoe store site.

Please show me ONE example of a real business which has such a set up.

>>> Are you really sure you want top mix this?
>>> I seriously doubt it.
>>>
>>> Do you know any small business who would want to have mixed employee
>>> logins/accountability with another small business?
>>> Honestly... no...
>>> But sometimes they share a same "physical" server (same owner for the 2
>>> shops)
>>>
>>
>> Nope, which is why they would have different sites. It makes no
>> difference whether they are on the same server or not - cookies are
>> domain specific, not server specific. One domain cannot access cookies
>> from another domain - it makes absolutely no difference whether they are
>> on the same server or not.
>
> As I explained, same domain.
> I'm paid to do as "his will", and had do do it.
> A person/company can own several little companies, and may want
> "CompanyGroup.com/smallCampany"
> The domain is "the same".
> Dangerous for cookies.
> I do not "always" have Vhosts, so I make sure it can work without vhosts.
>

And as I've explained - you are just arguing to argue, now. You're so
full of hot air if you were a balloon you'd never come down. Again,
show me one real company which does such tings.

>>> And again, separating sessions does not necessarily mean separating
>>> information.
>>>
>>
>> Yes, it does - because scripts using one session cookie will not be able
>> to access data from the other session cookie.
>
> You want these (sessions) to be seperate.
> And they can share databases if required, works like a charm.
> And for security, a script which needs only "read" access to a database,
> will have a login to this database with only "select" permission.
> I always create two users for databases, and I never use the one with
> full write permissions on the database if I only need read access in the
> script.
> I use prepared statements to protect from sql injection, but add this
> extra security.
>

More hot air.

>>> Sometimes you want things totally separated.
>>> Sometimes only "sessions" to be separated.
>>>
>>> And it's the one who pays you who decides.
>>>
>>
>> So, you use different domains and different hosts. No problem at all,
>> and separation of session information is guaranteed.
>
> With different domains, no big issue,
> But I'have already been asked the same domain, and the shop was the path
> after the domain name.
> When you say "it's not secure", they say "if you want this check with
> that much money? well make it secure and the way I want".
> What do you reply? you refuse the check? :-)
>

Again, more hot air.

But it's again obvious you either are arguing just to argue, or have no
idea of what you're doing - but are doing your best to support your
unsupportable argument.

So much for you. I like to discuss things with intelligent people.

<plonk>

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

		Sanitizing user input By: MikeB on Fri, 24 September 2010 05:42
		Re: Sanitizing user input By: Helmut Chang on Fri, 24 September 2010 07:59
		Re: Sanitizing user input By: MikeB on Fri, 24 September 2010 15:24
		Re: Sanitizing user input By: Web Dreamer on Tue, 28 September 2010 10:11
		Re: Sanitizing user input By: Jerry Stuckle on Tue, 28 September 2010 11:21
		Re: Sanitizing user input By: Web Dreamer on Tue, 28 September 2010 13:14
		Re: Sanitizing user input By: Jerry Stuckle on Tue, 28 September 2010 15:14
		Re: Sanitizing user input By: Michael Fesser on Tue, 28 September 2010 16:24
		Re: Sanitizing user input By: Jerry Stuckle on Tue, 28 September 2010 22:35
		Re: Sanitizing user input By: Web Dreamer on Wed, 29 September 2010 08:01
		Re: Sanitizing user input By: Jerry Stuckle on Wed, 29 September 2010 10:57
		Re: Sanitizing user input By: Web Dreamer on Wed, 29 September 2010 13:47
		Re: Sanitizing user input By: Jerry Stuckle on Wed, 29 September 2010 16:21
		Re: Sanitizing user input By: Web Dreamer on Thu, 30 September 2010 07:44
		Re: Sanitizing user input By: Jerry Stuckle on Thu, 30 September 2010 12:32
		Re: Sanitizing user input By: Web Dreamer on Thu, 30 September 2010 12:51
		Re: Sanitizing user input By: Web Dreamer on Tue, 28 September 2010 16:37
		Re: Sanitizing user input By: Jerry Stuckle on Tue, 28 September 2010 22:34
		Re: Sanitizing user input By: Web Dreamer on Wed, 29 September 2010 07:54
		Re: Sanitizing user input By: Web Dreamer on Wed, 29 September 2010 08:02
		Re: Sanitizing user input By: Jerry Stuckle on Wed, 29 September 2010 11:01
		Re: Sanitizing user input By: Web Dreamer on Wed, 29 September 2010 13:15
		Re: Sanitizing user input By: Jerry Stuckle on Wed, 29 September 2010 16:22
		Re: Sanitizing user input By: Web Dreamer on Thu, 30 September 2010 07:47
		Re: Sanitizing user input By: Jerry Stuckle on Thu, 30 September 2010 12:35
		Re: Sanitizing user input By: Web Dreamer on Thu, 30 September 2010 12:57
		Re: Sanitizing user input By: alvaro.NOSPAMTHANX on Fri, 24 September 2010 08:15
		Re: Sanitizing user input By: MikeB on Fri, 24 September 2010 15:06
		Re: Sanitizing user input By: Michael Fesser on Fri, 24 September 2010 17:12

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) ] [

]

Current Time: Wed Nov 27 11:08:02 GMT 2024

Total time taken to generate the page: 0.04104 seconds