Show DevBest [PHP 7.3^] Kooser Directory.

[Kooser6]

Kooser Directory.
A PDO wrapper for secure connections.

<

You must be registered for see links

>.

Features:
- Connection Manager
- SQL handler

Why:
This library makes the connection manager as well as the SQL handler injectable through service containers to make web developement faster.
This makes prepared statements easy to use to prevent SQL injection.

You can view the git repository at (

You must be registered for see links

).

This project is licensed under the terms of the

You must be registered for see links

.
(

You must be registered for see links

).

 

[Higoka]

you dont need to esacpe every function, true/false, null etc and i prefer the new array syntax $x = [...]; but personal preference i guess, apart from that its okay.

i personally would not use it myself because i can do the same without a wrapper theres not much difference and i can save some overhead for calling more functions and loading extra classes

 

[Kooser6]

The slashes avoid naming collisions.

You must be registered for see links

It's also a security enhancement due to the fact of I did not use slashes and the code was vulnerable to code injection they could inject code to modify the function. Now if there was a slash the class will look to the global namespace to prevent that piece of code to vulnerability. Paragonie Initiative Enterprise also states this issue. Here is an example:

<?php

namespace App;

class Foo
{
    public function bar($data) {
        echo count($data);
    }
}

$foo = new Foo();
$foo->bar([1, 2, 3]);

// returns 3.
  
}

Now here's what could happen:

<?php

// injected code.
// <?php
//
// namespace App;
//
// function count($data) {
//     return 24;
// }
//
// ?>

namespace App;

class Foo
{
    public function bar($data) {
        echo count($data);
    }
}

$foo = new Foo();
$foo->bar([1, 2, 3]);

// returns 24.

With the slash it still returns 3 because it's looking in the global namespace. Feel free to test this out for yourself.

Post automatically merged: Sep 30, 2019

Reason i made this wrapper is because not everyone knows how to properly secure their PHP web application.

Also you know how many classes are loaded in laravel and it still has optimal performance.

 

[M8than]

The slashes avoid naming collisions.

You must be registered for see links

It's also a security enhancement due to the fact of I did not use slashes and the code was vulnerable to code injection they could inject code to modify the function. Now if there was a slash the class will look to the global namespace to prevent that piece of code to vulnerability. Paragonie Initiative Enterprise also states this issue. Here is an example:

<?php

namespace App;

class Foo
{
    public function bar($data) {
        echo count($data);
    }
}

$foo = new Foo();
$foo->bar([1, 2, 3]);

// returns 3.
 
}

Now here's what could happen:

<?php

// injected code.
// <?php
//
// namespace App;
//
// function count($data) {
//     return 24;
// }
//
// ?>

namespace App;

class Foo
{
    public function bar($data) {
        echo count($data);
    }
}

$foo = new Foo();
$foo->bar([1, 2, 3]);

// returns 24.

With the slash it still returns 3 because it's looking in the global namespace. Feel free to test this out for yourself.

Post automatically merged: Sep 30, 2019

Reason i made this wrapper is because not everyone knows how to properly secure their PHP web application.

Also you know how many classes are loaded in laravel and it still has optimal performance.

Because laravel is made by competent people. (fyi its still not even close to good raw code)

btw who even mentioned anything about namespaces?

Post automatically merged: Oct 1, 2019

But yeah how do you expect someone to know how to build their own framework with symfony components + this when they can't even write secure php?

 

[Kooser6]

I mentioned namespaces because it's the main reason why i

you dont need to esacpe every function, true/false, null

. Also laravel is not very good in standalone use. My components are. Also i can build a framework given time that's faster than laravel. I have a lot more experience than you think .

 

[M8than]

I mentioned namespaces because it's the main reason why i . Also laravel is not very good in standalone use. My components are. Also i can build a framework given time that's faster than laravel. I have a lot more experience than you think .

from reading your code it doesn't look like it.

 

[MayoMayn]

Also laravel is not very good in standalone use. My components are. Also i can build a framework given time that's faster than laravel

21st century troller bois.
Is this Pettyjohn's long lost twin?

You must be registered for see links

Why so much duplicate code?
Plus, that's not even the proper way on how you'd get the IP of a request in PHP; what if your server is behind a proxy?

 $ip = isset($_SERVER['REMOTE_ADDR']) ? $_SERVER['REMOTE_ADDR'] : 'null';

Then this will just resolve to the host address.

You're late for april fools'

 

[LeChris]

Is this Pettyjohn's long lost twin?

Unsure what you mean, I've been using Laravel professionally for a year now.
If you feel irrelevant, go ahead and tag me next time instead of making passive insults without the audacity to bring attention to it.

In regards to the author, Laravel wasn't made for speed, it wasn't made for retros and it wasn't meant for any weird reason you might give that needs a few extra milliseconds. If speed is a concern, avoid PHP, but for most use cases it's fine.

I haven't looked at the code, but did see there was an unit test. Nice. Most people believe testing in production is viable

 

[Kooser6]

Plus, that's not even the proper way on how you'd get the IP of a request in PHP; what if your server is behind a proxy?

Not the proper way lol. I want you to show me the proper way lol. That's funny.

Why so much duplicate code?

Well i wrote that code in 2 hours. Maybe after updating it will be better lol.

You're late for april fools'

You might be the one late.

doesn't look like it.

Does not look like what? From the looks at it you do not know what the slash is. It does not escape lol. Do you know what your looking at.

 

[M8than]

Not the proper way lol. I want you to show me the proper way lol. That's funny.



Well i wrote that code in 2 hours. Maybe after updating it will be better lol.



You might be the one late.



Does not look like what? From the looks at it you do not know what the slash is. It does not escape lol. Do you know what your looking at.

I never said it did escape... That's why i was confused.

 

[Kooser6]

I never said it did escape... That's why i was confused.

My fault different person, but like what?

 

[M8than]

My fault different person, but like what?

didnt realise he meant explicit namespacing

 

[Kooser6]

didnt realise he meant explicit namespacing

What does my code look like?

Post automatically merged: Oct 1, 2019

Plus, that's not even the proper way on how you'd get the IP of a request in PHP; what if your server is behind a proxy?

I think i found your way.

You must be registered for see links

And you know you only run this against TRUSTED proxies. Key word.

Why? any HTTP headers come from the client and can be spoofed.

Look at:

You must be registered for see links

 

[M8than]

What does my code look like?

Post automatically merged: Oct 1, 2019

I think i found your way.

You must be registered for see links

And you know you only run this against TRUSTED proxies. Key word.

Why? any HTTP headers come from the client and can be spoofed.

Look at:

You must be registered for see links

@MayoMayn Hate to the the bearer of bad news but hes right you know. Any 'HTTP_' header can be set by the client.

 

[BIOS]

@MayoMayn Hate to the the bearer of bad news but hes right you know. Any 'HTTP_' header can be set by the client.

That's why you validate the input is an actual IP, and it has come from the proxy before assigning it as the primary user's IP.

How? Validate $_SERVER['REMOTE_ADDR'] is your trusted proxy's IP (

You must be registered for see links

, or lookup the IP ranges of your proxy), then validate the connecting IP header (i.e. $_SERVER["HTTP_CF_CONNECTING_IP"]) is an IP with FILTER_VALIDATE_IP.

You must be registered for see links

is pretty basic stuff.

Haven't looked fully through this but quality seems decent, made something similar to this a while ago for rate-limiting.

 

[M8than]

That's why you validate the input is an actual IP, and it has come from the proxy before assigning it as the primary user's IP.

How? Validate $_SERVER['REMOTE_ADDR'] is your trusted proxy's IP (

You must be registered for see links

, or lookup the IP ranges of your proxy), then validate the connecting IP header (i.e. $_SERVER["HTTP_CF_CONNECTING_IP"]) is an IP with FILTER_VALIDATE_IP.

You must be registered for see links

is pretty basic stuff.

Just read the other thread. X forwarded for has the same issue btw. Can still be set by any client

 

[Kooser6]

That's why you validate the input is an actual IP, and it has come from the proxy before assigning it as the primary user's IP.

How? Validate $_SERVER['REMOTE_ADDR'] is your trusted proxy's IP (

You must be registered for see links

, or lookup the IP ranges of your proxy), then validate the connecting IP header (i.e. $_SERVER["HTTP_CF_CONNECTING_IP"]) is an IP with FILTER_VALIDATE_IP.

You must be registered for see links

is pretty basic stuff.

Haven't looked fully through this but quality seems decent, made something similar to this a while ago for rate-limiting.

This is extra validation that is not needed, if you first check the `HTTP_` vars i can spoof any IP. ANY is the key word. Even a valid IP that is not mine. The reason `REMOTE_ADDR` is the best option is it can not be spoofed. Apache populates `REMOTE_ADDR` from a TCP socket that it uses to communicate with your browser. It is impossible to influence this variable over the open internet because of the

You must be registered for see links

. If the client and the server is on a broadcast network, like wifi, then you can sniff the wire and complete the handshake. The best way is to first see if `REMOTE_ADDR` is a trusted proxy, if so then use the proxy header, else just use `REMOTE_ADDR`. From a security standpoint validating `REMOTE_ADDR` is pointless. To sum this up the way i am using `REMOTE_ADDR` is to just protect each individual user from session hijacking, why would i use `HTTP_` vars that can be spoofed.

 

[Ecko]

He's right, but he should still be checking proxies.

 

[Kooser6]

He's right, but he should still be checking proxies.

Only on trusted proxies lol.

 

[BIOS]

This is extra validation that is not needed, if you first check the `HTTP_` vars i can spoof any IP. ANY is the key word. Even a valid IP that is not mine. The reason `REMOTE_ADDR` is the best option is it can not be spoofed. Apache populates `REMOTE_ADDR` from a TCP socket that it uses to communicate with your browser. It is impossible to influence this variable over the open internet because of the

You must be registered for see links

. If the client and the server is on a broadcast network, like wifi, then you can sniff the wire and complete the handshake. The best way is to first see if `REMOTE_ADDR` is a trusted proxy, if so then use the proxy header, else just use `REMOTE_ADDR`. From a security standpoint validating `REMOTE_ADDR` is pointless. To sum this up the way i am using `REMOTE_ADDR` is to just protect each individual user from session hijacking, why would i use `HTTP_` vars that can be spoofed.

You can't spoof it if you validated the request came from the proxy in the first place. REMOTE_ADDR is fine if you aren't using a proxy/CDN, sadly most people do these days; so solely relying on REMOTE_ADDR won't do a lot for these setups if you're using it for fingerprinting (every session will be locked to the CDN's IP which breaks your implementation...).