Re: Multi-select inputs and naming
| From: | Dan Phiffer | Date: | Mon, 10 Mar 2003 19:36:41 +0000 |
| Subject: | Re: Multi-select inputs and naming | ||
| References: | 1 2 | Groups: | php.general |
| Request: | Send a blank email to php-general+get-139012@lists.php.net to get a copy of this message | ||
> Unless you're ashamed to be running php, or don't intend to be spending as
> much time on security as you should, why would this be an issue? If your
> app is well-written, the knowledge that it's implemented with php
> shouldn't benefit a potential attacker. You know what they say about
> security through obscurity...
Hehe, yeah I am being somewhat anal here. I was hoping that with
search-friendly URLS (i.e. /issues/2003/mar/ rather than
/issues.php?year=2003&month=mar), I could have the added security benefit of
obscuring the back-end technology. This is more from the theoretical than
practical line of thinking, so I'm not too worried.
While I agree that if the app is well-written it shouldn't matter, but I
figure it couldn't hurt as an added security net. I have another question
reguarding the security implications of "source readable" PHP projects, but
I'll save that for another thread.
> > I'm hoping there's some alternative technique I've missed...
>
> I guess you could use javascript to create/set individual hidden form
> fields for the items selected, but if the user has javascript disabled
> your form ceases to function.
I guess this question was coming from a "couldn't they have designed in a
cleaner way?" perspective. Don't get me wrong, I think the way PHP does an
outstanding job of handling these particular kinds of form submissions, I
just figured there might be an alternative syntax.
Thanks for the responses,
-Dan