gizmola

Is this some psuedocode language you've made up, because that is not php syntax. Provide a real code snippet if you would like us to try and help you understand what is going on. If you are trying to pass an interpolated string as an argument to a function, and that interpolated string includes a function call, no that will not work. You would have to concatenate the string together with the function calls.

Of course not. Plus we share an awesome albeit common first name apparently

Most websites do use hashes. Sites that either encrypt/decrypt or store a plaintext version of the orignal password are few and far between in my experience. It's far preferable to store a hash exactly because it can not be reversed. The attack against hashes then, IS based on either brute force, educated guessing, or dictionary/rainbow attacks. One of 2 things can happen: 1. The site allows brute force attacks: --I may not notice that you have a bot that repeatedly tries to login to an account name using a file comprised of words and phrases and minor variations of those words. 2. The site has a vulnerability that discloses the actual stored hash value. --While this is a bad situation, it's not actually catastrophic with a hashed password, and assuming a salt was used, renders the disclosure virtually irrelevant. --However, if not salted, this is where people using common passwords becomes a substantial problem because the cracker can be assumed to have a rainbow table that will match any number of poorly constructured passwords. This site and most forums on the web utilizes open source software, so the details of their security are available for inspection. It seems that your argument boils down to the fact that you can not be bothered to keep track of a password you use for it on an intermittent basis. There are keychain like tools built into browsers, not to mention addons that allow you to keep track of those, if you want to avail yourself of them.

There are two that I own, each which has some good material in them. They are both a bit dated at this point but I don't know of anything in particular that makes either of them less relevant. http://www.amazon.com/Essential-PHP-Security-Chris-Shiflett/dp/059600656X/ref=sr_1_1?ie=UTF8&qid=1309488153&sr=8-1 http://www.amazon.com/php-architects-Guide-PHP-Security/dp/0973862106 Neither one is a cookbook however.

Yes, keep telling yourself it's because I don't understand the syntax to alter a table. Do you even understand your own approach? -You have a table named cookie, that you are changing from the name of CurPrice to 'date'. What happens tomorrow when you run this script and the column is no longer named CurPrice. What value do you think your script will have?

Please use code or php tags around your code. -Proper syntax for construction of an object is $ob = new Objects(); -In your function get_name, you need return $this->name; When you get a blank page, there should be an error in your error log describing the problem (a syntax error in this case).

Currently you are using AND. It's not clear to me from your example, because your code only illustrates one table, and a handful of fields, but in general, yes there is no point on including empty criteria so you'll need to detect that. Any query that includes LIKE '%SOMETHING%' will tablescan. No indexes can be used. This will perform worse and worse as your databases increase in size, however it might be acceptable for you if your tables will be small, and your mysqldb is performance tuned. There are alternatives to what you're doing like the use of mysql fulltext search, or specialized search engines like sphinx. Those solutions also have the advantage of allowing you to search for phrases.

I tested a few things, and you're not doing anything with formatting of columns in the profile, as I was for example able to make birthday the string: "Birthday". You are not filtering input it seems. Go look at the phpftester profile and you'll see an xss exploit in the "slogan". I tested a bit of your session stuff, and that seemed to be ok. Tried some sql injections with no success. In the mail system, I was able to mail to myself. Putting garbage in the To: leaks an error: Warning: mysql_num_rows() expects parameter 1 to be resource, boolean given in , so that indicates that you're not assigning the result of your insert query to a variable and checking it before you try mysql_num_rows(). The design is pretty bland, but I'm sure you're going to work on that. It's a game, and the design should reflect that.

Yes, well if I understand you correctly, your webroot (/) is the parent directory. When the rewriterule attempts to load /index.php, it is looking at the root directory (the document root) and it of course can not find the index.php. If this supposition is correct, then adding: RewriteEngine On RewriteBase /www.mydomainname.com/ //etc... May fix your problem right now, although you would most certainly not want or need that in your production environment.

You cast the objects to the data type you want. If you are doing this so you can test against is_numeric, you would have to cast to a string, then test. foreach( $xml->sub_key->children() as $child ) { $value = (string)$child; if (is_numeric($value)) { echo "$value is numeric"; } else { echo "$value is not numeric."; } }

Can't blame him. Whether your stuff gets implemented is dependent on that there is not some idiot on the top who vetos because it's against some stupid axiom he made for that special occasion. There may be a million votes for the proposol, and none against, but that doesn't matter if someone decides that his personal vision is more important than a community decision. That certainly does happen, but if you never even attempted to submit the patches, it's guaranteed that they won't be accepted. I was basing my rant on particular encounters with certain members of the PHP Group. I can't be bothered going into details, but as a result I ultimately decided that I no longer wanted to contribute. Of course there needs to be leadership, but there is a such thing as bad leadership. Agree 100%.

MrAdam's suggestion is what I'd run with. Just wanted to clarify that Fugix's code would not work for you.

Look at the jquery manual here: http://api.jquery.com/jQuery.get As noted, post is a shorthand for the generic ajax function.

Those tutorials show you how to implement it with jquery. Substitute javascript for jquery and I'm sure you'll find plenty.

Hey Nate, please none of these types of questions. This forum is not a substitute for google. We help people code here. http://tinyurl.com/623ydau

Nice pickup by EdwinPaul That error would not allow it to parse, so I'm not sure what that says about the state of your current script.

All the post variables come in through the $_POST. You neglected to assign your $Where variable to anything, so that is why it is empty. As for date, you need the date to be in a format where it can be parsed reliably unless you want to just accept any old thing. If you don't want to do it through javascript you'll inevitably get problems. Probably the best solution in that case is to break it into 3 seperate form elements for Year/month/day, pass those and assemble them into a string later. Of course you'll still risk invalid dates via typos or people misfilling the form, and even javascript is not a panacea, but it will greatly improve the results for your legitimate users.

You should seriously consider mjdamato's advice in restructuring your user_equiped_items table. What you have implemented there is a "repeating group" with the primary_id, secondary_id, melee_id. You could normalize that table and gain a lot more flexibility of design and ease of querying at a minimal cost. You would simply need to add an equip_type table that describes the equptypes (primary, secondary, melee, etc) and then you create a row per item that is equipped. Makes your joins simple and you don't have to do helacious queries liket he one mj cooked up for you. Additionally when you add a new equipment slot, instead of modifying the database structure you add a new equiptype and you're off and running.

Fugix, do you not see a problem with that code? You might want to test a suggestion like that before you post it next time.

That is not a reason to do something so fundamentally wrong. If you were a carpenter and your boss said: "I want you to build an inverted pyramid out of glass with a bandsaw" and you went to the world's largest carpentry forum where experts with decades of experience and expertise explained to you that what you were talking about was not only ridiculous, but suicidal and they would not endorse or support the idea, to which you replied: "the boss told me to do this" do you think that they'd suddenly change their tune? I'm sorry that your "boss" is pulling your strings, but that does not effect us or our integrity. If you proceed with this idea you'll be sorry. Ad-hoc changes to the data dictionary/structure of a table are not what rdbms were made to do. Having multiple tables instead of multiple rows, or multiple columns instead of multiple rows is not how you design or use an rdbms. Database tables are optimized and have features that allow them to do amazing things, but only when you structure them properly. There are names for these rules (normalization) that come right out of the theory that was used to create them by the originator (Dr. Ted Codd). TenDolla provided you a simple effective structure that could be used as a starting point. It's clear you have not even begun to consider what the SQL statements would be or how you would compute them, nor do you have any understanding of how your planned structure will not perform when data is loaded. With a proper structure you could easily do all sorts of things like graphing prices, comparing prices for individual dates and even date ranges that will be nearly impossible to accomplish with a table with 10's to hundreds of columns (nearly all of which for any given row that will be empty). Truly, what you're saying you want to do is bizzarro. If this seems harsh, it's meant to be. There is nothing more infuriating to the experts in this community, who offer sage advice to people for free, as when our advice is ignored by people for silly reasons who don't know any better. I sincerely hope this is a wakeup call for you.

Can't blame him. Whether your stuff gets implemented is dependent on that there is not some idiot on the top who vetos because it's against some stupid axiom he made for that special occasion. There may be a million votes for the proposol, and none against, but that doesn't matter if someone decides that his personal vision is more important than a community decision. That certainly does happen, but if you never even attempted to submit the patches, it's guaranteed that they won't be accepted. One thing I like is that he just removed a lot of the backwards compatibility garbage that has been on the deprecation list for a long time, although even there, he included short open tags, which I think have value for a lot of people in templating. I also think it's interesting that certain constructs perform so poorly that you have to learn through the grapevine to avoid them, and use the techniques that perform. Overall, I think this has caused some healthy dialogue to occur and may shake off some complacency.

That's actually one of the issues that has kept me from writing about this, because I want to present both sides of the discussion and unless I have time to do the topic justice, I'm not going to bother. In looking at it, it's more interesting as an idea than in a practical sense. It's good to hear that at least he's talking to the core devs now.

This topic has been moved to PHP Coding Help. http://www.phpfreaks.com/forums/index.php?topic=337285.0

I think I am starting to understand where you are confused. Unit tests are not designed to find out what you don't know about how your code works, they exist to insure that what should be true, still is, even after you've changed things. If you know in advance that an array will break your add_numbers() function, unit tests are not designed to tell you that. Your function should handle that in a predictable manner.

What you're trying to accomplish is testing units of code. "Given X -> expect Y". What you get from unit testing is Pass or Fail. So if you are testing a function that takes a variety of different input options, you need to write a test case for each potential input if you want any granularity of what failed. In order to do that you need to control input. So this is done either by hardcoding iput, or using fixtures, which allow you to set your environment back to known/default state.