Sanitor (PHP input filtering/sanitization improvement)

[B Roeser]

Hi there,

I stumbled upon the League of Extraordinary Packages today and found it very interesting.

I'd like to present one of my own packages, which might be of interest to you.

It is called Sanitor and is basically an enhancement over the built-in filter_input(), filter_var() and filter_has_var()-methods of PHP's filter extension:

https://broeser.github.io/sanitor/

It works with PHP 5.4, 5.5, 5.6 and 7.0 (according to Travis CI, I have sadly only tested it in a live project on 5.6).

I strived for great code quality, so I have thoroughly tested the package with 100% code coverage.

It has a GitHub page and a README (same content) that should (hopefully) explain the package in more detail.

The package conforms to rules 4-10 of the league.

I currently don't totally follow PSR-2 – my opening curly braces of functions and classes are on the same line – but as far as I can remember, that's the only PSR-2 violation. Obviously this could easily be fixed.

Do you think the package is interesting and would be a good addition for the league?

If yes, I could easily adapt it to PSR-2, change the namespace etc.

If not, that's fine too, I'd like to hear your thoughts and feedback.

Yours,

Benedict

[Woody Gilk]

I guess my first reaction would be "why doesn't this use PSR-2"?

A couple of the thrown exceptions might be better as InvalidArgumentException.

Other than that, the package looks pretty good. I'm not really sure it meets the criteria for _why_ it should be included in League, since there are any number of other packages that do similar things.

--
Woody Gilk
http://about.me/shadowhand

--
You received this message because you are subscribed to the Google Groups "thephpleague" group.
To unsubscribe from this group and stop receiving emails from it, send an email to thephpleague...@googlegroups.com.
To post to this group, send email to thephp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/thephpleague/b115a651-e8e0-4f71-ac58-db6f38857a24%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ben Corlett]

Hi Benedict,

Good work on building this package!

So, as Woody put to you, why this package over another?

Further, the session/request filtering, I’m thinking now for the purposes of avoiding those superglobals, would it be better to inject a Symfony Request object in? At least that way you could inject `Request::createFromGlobals()` as a dependency…

Don’t let the scrutiny you’ll receive think we don’t _like_ your package, we need to perform this due diligence to ensure that we keep close to our core focus as a group.

Ben Corlett
Director
P: 02 4970 2244	M: 0438 732 218
A: 11/1 Reliance Dr, Tuggerah NSW 2259

To view this discussion on the web visit https://groups.google.com/d/msgid/thephpleague/CAGOJM6LyG37yfjhZwDdNPZZS5PuuT4gCqwwKwf8tJCjxtnQhfw%40mail.gmail.com.

[Woody Gilk]

On Mon, Feb 29, 2016 at 4:11 PM, Ben Corlett <he...@webcomm.io> wrote:

Symfony Request object

Does everyone in the world use Symfony Request?

[Ben Corlett]

Not at all, it’s a pretty good alternative to superglobals however…

Ben Corlett
Director
P: 02 4970 2244	M: 0438 732 218
A: 11/1 Reliance Dr, Tuggerah NSW 2259

[Hari K T]

Not at all, it’s a pretty good alternative to superglobals however…

The good idea will be pass the globals to construct. So no one need to worry about whether it is $_SERVER or anything . So it can be also taken from $request->toArray() ( Don't recall if there was to array in symfony , but there is something I guess ) .

[Ben Corlett]

Yeah I considered recommending that however it makes for a horribly ugly constructor. 

Ben Corlett

Director

Sent from my iPhone

Please excuse my brevity

On 1 Mar 2016, at 3:31 PM, Hari K T <ktha...@gmail.com> wrote:

Not at all, it’s a pretty good alternative to superglobals however…

The good idea will be pass the globals to construct. So no one need to worry about whether it is $_SERVER or anything . So it can be also taken from $request->toArray() ( Don't recall if there was to array in symfony , but there is something I guess ) .

--

You received this message because you are subscribed to the Google Groups "thephpleague" group.
To unsubscribe from this group and stop receiving emails from it, send an email to thephpleague...@googlegroups.com.
To post to this group, send email to thephp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/thephpleague/CAESZFt%2BzCTJ-Jv%3D_Cym1D8-aAd7g-rd5OaDE_5Mx-ga3DAj43w%40mail.gmail.com.

[B Roeser]

Hi Woody,

On Monday, February 29, 2016 at 5:33:01 PM UTC+1, Woody Gilk wrote:

I guess my first reaction would be "why doesn't this use PSR-2"?

There is no technical reason.
I personally prefer a slightly different style of putting my braces, and as the project started out as personal little helper tool I used that style and stuck to it.
However as I said, I could easily change it, if it's a problem.

A couple of the thrown exceptions might be better as InvalidArgumentException.

Yes, that's true.
 

Other than that, the package looks pretty good. I'm not really sure it meets the criteria for _why_ it should be included in League, since there are any number of other packages that do similar things.

It's true that every framework and some other packages implements proper input sanitization.
IF someone ever needs a tool that does only input sanitization and does it well, I'd suggest my package. ;)

Yours,
Benedict

[B Roeser]

Hi Ben,

On Monday, February 29, 2016 at 11:12:08 PM UTC+1, Ben Corlett wrote:

Hi Benedict,

Good work on building this package!

So, as Woody put to you, why this package over another?

Thank you!
See my answer to Woody.
 

Further, the session/request filtering, I’m thinking now for the purposes of avoiding those superglobals, would it be better to inject a Symfony Request object in? At least that way you could inject `Request::createFromGlobals()` as a dependency…

The package currently has NO dependencies except of PHP >=5.4 and I'd like to keep it that way. It would be possible though to add a bridge for using a Symfony Request object with Sanitor, however in that case it is probably easier and saner to just use Symfony directly.
I think my usage of superglobals in this context is okay.
 

Don’t let the scrutiny you’ll receive think we don’t _like_ your package, we need to perform this due diligence to ensure that we keep close to our core focus as a group.

 

That's ok. :)