On May 14, 2015, at 8:37 PM, Jigme Datse Yli-Rasku <jigme.da...@gmail.com>
> On 15/05/14 18:19 , Karl DeSaulniers wrote:
>> On May 14, 2015, at 8:09 PM, Aziz Saleh <azizsa...@gmail.com> wrote:
>>> On Thu, May 14, 2015 at 9:05 PM, Karl DeSaulniers <k...@designdrumm.com>
>>> Hello Everyone,
>>> Have a quick question. Was reading some material and wanted some Players
>>> I know w3schools is not the de-facto on everything, so I wanted to know how
>>> reliable is the information on this page.
>>> Namely the @ symbol before SQL Values and because this talks about SQL and
>>> not MySQL specifically, does this not apply to MySQL?
>>> To my uneducated eyes it seems legit. Any clarification is greatly
>>> Karl DeSaulniers
>>> Design Drumm
>>> That is preferred in PHP as well. The SQL/MySQL isn't specifically doing
>>> the replacement, but rather the driver object. Using parametrized queries:
>> Thank you Aziz,
>> Interesting link, thank you for that. I have not worked with prepared
>> statements on my own, just in WordPress.
>> So the @ symbol is a preferred method even outside the SQL world because?
>> What specifically is the @ symbol doing?
>> From what I read, and from what you just mentioned,
>> it's the PHP->SQL driver that check this @ symbol and treats the data as
>> literal text?
>> Meaning it will not execute the text that comes after the @ symbol as code.
> If I understand correctly it is not the @ symbol itself which is the thing
> you should be looking at. What you should be looking at is how your
> programming language handles prepared statements. What I see is that the @
> symbol is how ASP.Net defines the variable name, and also the variable
> I am not sure about this, but it looks like PHP uses : for the same function.
> I am even less sure about this, but I think with prepared statements you can
> also define what "type" of data is being passed. So if you try to pass a
> "string" (ie. something that cannot be converted to a number) to a "number"
> defined variable, you will get an error thrown. If you use a catch statement
> that error can be handled by your code, rather than PHP handling it in
> default manner.
> It really has been a long time since I have been hands on with any of this,
> and there is a good chance at least some of what I am saying is wrong.
> The point of prepared statements is that what variables you are passing
> through them, they are passed as literal values, rather than simply putting
> them through as straight text put into your string you are passing to SQL.
> Even if the string ends up "breaking" your query in a way that can harm
> either security of data, or your database itself (also a security issue), it
> is not passed in a way that SQL handles as such.
> I discovered an issue on one of the web apps I used where I would get a SQL
> error message if I entered certain strings into the input field. Even though
> what I was doing wasn't at all trying to test for it, my inputs made it clear
> what was going on.
> With that amount of "what is going on" figured out. I could send a
> meaningful bug report that got this issue fixed. Most people using the site
> would have had no idea what was happening.
> If I recall, I was putting a " or ' in my input, thus closing the string,
> which then left the rest being interpreted as SQL code.
Ok, so understand my own situation, the method I have been using, mysqli real
escape string is suffice?
Or is the @ symbol is the better preferred method?
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php