vinny42
-
Posts
411 -
Joined
-
Last visited
-
Days Won
3
Posts posted by vinny42
-
-
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.
-
Well most people make a habit of providing their address in a format recognized by their post/mail person.
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)
-
his is a fairly common thing to do with 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.
-
is for example...
20/08/2013
or
20/8/2013If 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.
-
That means 1-100 is going to be assign to 1st street only.
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.
-
it did not like the ' symbol.. so before submitting the update I now have the program scan every character and escape this little sucker... like so.. \' and all is well..
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.
-
This also means you can use the many date/time functions without prior conversion to the expected format.
You don't have to convert them explicitely, buit the database will do a conversion internally.
It seems so much easier to work with than MySql's DATE or DATETIME
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.
-
Actually character classes support ranges with hyphens,
I knew that, I dind't know that 0-3 is a valid range. :-)
-
The output is perfectly valid.
It's a perfectly valid IPv6 address, it's completely invalid IPv4 response. :-)
-
varchar(255) has a limit of 255 chars, varchar(1000) has a limit of 1000 chars.
Yup, and just about every database management tool will suggest 255 as the default limit.
But it a simple matter to look at the structure for posts_comments and see that it is a "longtext" capable of handling a whole lot more than 255 characters...
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().
-
How can I better protect the process so that strpos() is checking $line for exact matches of email, & password?
I'd split the lines from the file into separate vars for the email and the password, and simply compare without strpos().
-
I think he meant "on my entire street" rather than "planet"
-
the sooner you get into the habit of using parameterized queries the betterIf 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 useand you will regularly get queries that are very slow for no apparent reason, and there is nothing you can do about it except hope thatthe database's statistics will cause the planner to reconsider soon.this effectively makes the security offered from the prepared statement superfluousNot 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 approvesomething 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 guaranteethat 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 closerthan a prepared statement, but a properly setup databaseclass can do the job quite well.
-
but not the syntax for sending the current time in hour:minute am/pm format.
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).
You will literally not find a person on this entire planet better than Barand when it comes to databases.
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.
-
I will def use preg_match for that.
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.
and if it comes up a match then i can prevent them from ordering.
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.
-
as long as the file is offered for download, then it cannot be executed on your server by a web browsing user.
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.
-
There is no magical set of numbers to put in your config, because the requirements depend entirely on what kind of workload you have, what does the database do, etc.
Having 1k people online doesn't say anything about how many pageviews you are getting what kind of work you do per pageview, etc.
How big is your database? are you using InnoDB or MyISAM, what kind of disks does the server have
Did you run a load test to see where your server is currently struggling?
Anyway, you should read some articles about tuning MySQL, there is a lot of good information in http://www.mysqlperformanceblog.com/
MySQL search query failing
in MySQL Help
Posted
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.