vinny42

I clearly wasn't awake yet, sorry :-)

There is no OR in the second query. :-) However, the first query will also grab records with grupa_artikla = '1HU', the second only '1HP', so my guess is there are no records that have '1HP' that meet the other requirements.

htaccess *only* controls what the webserver itself can do with a folder or file. It has no control over what PHP or any other process on the server does with them. In short: if it's not an HTTP request then htaccess has no control over it.

Many do, but a significant number don't. They either don't care and assume that some human will see the address and fix it, of they simply don't understand how the website wants the address to be supplied. And I understand that perfectly; every webdesigner has his own ideas about what's userfriendly and some just aren't. I've had fights (well, allmost) with collegues about the dutch zipcode which oficially has no space in it: "1234AA" but many poeple do type a space: "1234 AA". Fixing it is simple; just strip everything that's not a number or a letter. Yet they wanted to give an error if the format was not "1234AA", meaning that half of the customers would get a very silly error about a space that is of no consequence anywhere, ever. To make an increasingly long story short: if the autosuggest can't find it, it should tell the customer that the *format* is not recognised, not that the address cannot be found (because it is also very popssible that your address database doesn't yet know about some of the newsest addresses)

True, but you have to make it pretty darn flexible. If the customer is used to entering his address a certain way and your autosuggest can't figure out what he means, he'll never get the right suggestion.

If both (or more?) formats are used then be carefull with Barand's solution, you *MUST* check to see what the exact format is before you convert. If the format is m/d/y then you might interpret 12/30/13 as the 12thday of the 30th month, and MySQL will spew the infamous crap of "0000-00-00". Some sort of regexp is in order, and you should probably configure MySQL to use "traditional" mode so it eill throw errors instead of silently useing 0000-00-00.

I think what josh meant is you should make your users pick a format that they want to use to enter their address, like "<housenr> <streetnr>" or "<housenr> <boulevardname>" and give them separate fields to enter each bit of information into. Then you can assume that whatever is entered into the housenr field is a house number and you don't have to try to work out how it was written. Here in Holland we do the same for your sometimes bizar adresses, we have a separate field for the provence, the city, the streetname, the housenumber, the additions to the housenumber and the zipcode. It's much easier for the user to split the information when entering it into a form, than for the script to split a combined string into it's parts.

Uhm.. you *are* using mysql's own escape functions, right? if not then you have to do that *NOW* because you're completely open to SQL injection. Don't escape the3 quote manually, because the quote is only one of many characters that need to be escaped and you have no way of doing that right withcustom code.

You don't have to convert them explicitely, buit the database will do a conversion internally. In what way do you feel it's easier? Because I usually get this argument from poeple who didn't know that you can do things like: SELECT NOW() + INTERVAL 1 WEEK; where the '1' can also be a value from a field in a table. and you can do things like SELECT date_field - other_date_field; The advantages become more obvious in other databases where you can also store the timezone in the datetime, which means your application can tell the database which timezone each value is in and in which timezone the result should be returned. This is a lifesaver when you deal with countries that have daylight saving time.

I knew that, I dind't know that 0-3 is a valid range. :-)

It's a perfectly valid IPv6 address, it's completely invalid IPv4 response. :-)

Yup, and just about every database management tool will suggest 255 as the default limit. So it's probaby not that field that's causing the problem. What is the exact errormessage?

[20-30] matches any character 0,2,3 and -. (I trust that you googles a few tutorials about how regular expressions work? That saves you a lot of these kinds of "beginners" problems. :-) "20-30" is not a number, it's a string, and it is much more efficient toe use strpos to find that in a variable.

Sounds like you are trying to insert into a VARCHAR column, they have a default limit of 255 characters. backup your database, and use an ALTER TABLE statement to change the offending column from VARCHAR to TEXT. Doing this is very low-risk, but do *NOT* skip the backup, and check if you can actually restore the backup on a test environment before yoou risk destroying your data.

Images in HTML must either be called using an SRC element and cause a seprate hit on the webserver which would then fetch the blob from the database (which is bad idea because it loads up your database with filesystem work) or you must encode the blob data as base64 into the HTML source, another not so good idea. The best solution is to cache the images on disk and link them the usual way in the IMG tag. That way you can instruct the clients not to refresh it for a fe weeks, which saves lots of bandwidth.

it does, but you are trying to push an array into itself. Stop uising the same variable name for everything.

Sockets are a generic TCP/IP thing, they have no concept of "array". If you want to send an array of data then you will have to transform the array into some binary format, send it across, and tansform it back. Look at serialise() and json_encode().

I'd split the lines from the file into separate vars for the email and the password, and simply compare without strpos().

If you mean "write a class that does the calls to escape_string calls for you" then yes, do it, yesterday. If you mean "use prepared statements" then no, don't do that unless you know what you are doing. Why: prepared statements are safe against injection because they parse the query before there is any data in it so the data can never be mistaken for query grammer. Unfortunately this also means that the query planner cannot take the data into account when making the plan and so it cannot reliably choose which indexes to use and you will regularly get queries that are very slow for no apparent reason, and there is nothing you can do about it except hope that the database's statistics will cause the planner to reconsider soon. Not at all, because your validation doesn't validate against SQL injection. If for example your application expects a person's bio as a text, then you would approve something like "I was born in 1' OR '1'='1". It's a strange text, but valid, so you let that pass, put it in the query and you're hacked. Perhaps more importantly; your input validation only checks incoming data, it does not guarantee that the data is still safe by the time it gets to the query. Safe doesn not only mean that no hackers have been at it, it also means that the value doesn't make the query accidently destroy your data. So no, always do your database related checks as near to the query as you can, and it doesn't get much closer than a prepared statement, but a properly setup databaseclass can do the job quite well.

That's because you are trying to do something that nobody else is doing. In databases it's common practise to use a DATETIME column and to store the current time using NOW(); CREATETABLE foo (id integer, mydate DATETIME); INSERT INTO foo (34, NOW()); The DATETIME column is used because you can compare it against the current time, format it to whatever you want, etc. Storing a date as a string means you cannot do *anything* with that date other than print it, and by the time you get around to "doing it properly", you'll have a lot of trouble converting all your strings to dates (which is an art in itself). Ouch, that hurts... :-)

And don't get tempted to write new rewrite-rules for every user, simply rewrite al URL's to index.php and use PHP to examine the URL and decide what todo.

Regexps are extremely usefull but if you are only looking for a substring then strpos() and the PHP's other string functions are usually much faster. You'll ask them to correct it. :-) Remember the goal is to accept as many orders as possible, the filtering is just to make things easier for the people who process the orders.

That is only true if the webserver cannot execute files (which meanss PHP's exec() and system() must be blocked) and the webserver has no way of placing any files at any location where the server itself might execute it. A famous example is a system where MySQL is running under root (because the admin doesn't know the risk), and the webserver has a simple SQL injection problem (which are frighteningly common). Al you have to do is SELECT INTO OUTFILE "/root/.login" "adduser hacker"; and the next time the root logs in, the system is hacked. So no, just because the file is uploaded to a webserver which s configured to offer downloads doesn't mean you're safe, not by any strech of the imagination. Ditto for ZIP files by the way, because your server has programs to unzip them. if you are going to allow users to upload files you have to make sure that the location where they are stored is utterly impossible to get to from the filesystem, such as a database.

Preprogrammed formats have a habit of being very complex. Here in the netherlands we have you can live at the "2e van Zwinden straat 24 A III L" That's the second "van zwinden" street, number 24, first floor, third appartment on the left side of the hallway. Alternatively you can live at the front or the back of the building. So, you cannot disapprove a housenumber because it's written as "24A3V", because that really is their housenumber. If you are going to filter, make sure you don't just discard suspect data because changes are that you have lots of false positives. You should probably also look into the FULLTEXT and fuzzy-string features that the popular databases have, they allow you to do things like work out how closely the entered data matches a stopword, which may be significant when deciding wether it is a bad string.