gizmola

I'm not sure why you would use 3 columns. If you want to explain what you are trying to do, I can help with the proper database design.

benanamen's main point is probably the issue. Probably your version of php was updated and the mysql_ functions are deprecated and have been removed entirely. You need to either use mysqli_ or pdo, and adjust your code accordingly, but that could be a substantial undertaking, as it should effect your entire code base any place that mysql is being used.

I took your code and did the moving for you. Once you start moving things into sections, the logic issues with your current code start to become more obvious. What's obvious at present is that the html header code needs to be either separated or moved inside a function so that it can be rendered before the form code is rendered OR before the error code is rendered. <?php ini_set('display_errors', 'On'); error_reporting(E_ALL); require_once('functions.php'); function outputErrors($sql_errors) { foreach($sql_errors as $name => $msgs) { echo('<h4 class="error">' . $name . ': ' . $msgs . '</h4>' . PHP_EOL); } } function validateInput() { global $errors; $status = true; if($_POST['fname'] == "") { $errors['fname']="Please enter your first name"; $status = false; } if($_POST['lname'] == "") { $errors['lname']="Please enter your last name"; $status = false; } return $status; } //end user validation function display_form() { global $errors; ?> <form action="stickyForm.php" method="post"> <label> <input id="fname" type="text" name="fname" size="15" placeholder="First Name" value ="<?php if(isset($_POST['fname'])) echo $_POST['fname'];?>" > <input type="text" name="lname" size="20" placeholder="Last Name"><?php echo !empty($error['lname']) ? $error['lname'] : '';?> <input type="text" name="orgName" placeholder="Organization's Name"maxlength="50"> </label><br /> <label> <!--new row --> <input id="address" type="text" name="address" size="15" placeholder="Street Addresss" maxlength="50"> <input id="city" type="text" name="city" placeholder="City" size="10" maxlength="25"> <select id="state" name="state" placeholder="State" value=""> <option value ="">Please choose a state</option> <?php states($state); ?> </select> <input id = "zipcode" type="number" name="zipcode" placeholder="Zip Code" size="5" maxlength="5"> </label><br /> <label> <!--new row --> <input type="text" name="phone" placeholder="Phone Number:(including area code)" size="10" maxlength="10"> <input type="text" name="fax" size="10" placeholder="Fax Number: (including area code)" maxlength="10"> </label><br /> <label> <!--new row--> <input type="text" id = "email" name="email" placeholder="Email Address" /> <input type="text" id = "confirmEmail" name="confirmEmail" placeholder="Confirm Email Address" /> </label><br /> <label> <!--new row --> What would you like help with? <table id="projectOptions"> <tr span=2> <td><input type="checkbox" name="projectOptions[]" id="projectOptions[]" value="socialMedia">Social Media</td> <td><input type="checkbox" name="projectOptions[]" id="projectOptions[]" value="webContent">Web Content Management</td> </tr> <tr> <td><input name="projectOptions[]" type="checkbox" checked="checked" id="projectOptions[]" value="marketingMaterial">Marketing Material Creation</td> <td><input type="checkbox" name="projectOptions[]" id="projectOptions[]" value="seo">SEO (Search Engine Optimization)</td> </tr> <tr> <td><input type="checkbox" name="projectOptions[]" id="projectOptions[]" value="videoEditing"> Video Editing</td> <td><input type="checkbox" name="projectOptions[]" id="projectOptions[]" value="webDesign">Web Design</td> </tr> </table> </label> Overview about the project:<textarea rows="5" cols="10" placeholder="Overview of Project"></textarea><br /> If you are not a robot, what year is it? <input type="text" name="year" size="4" maxlength="4"><br /> <input type="submit" name="submit" value="Contact Me!"> <input type="reset" name="reset" value="Cancel"> </form> <?php } $errors=array(); //validate user's input if(isset($_POST['submit'])) { validateInput(); if(count($errors) != 0) { display_form(); } else { display_form(); } $sql_errors = array(); $mysqli = databaseConnection(); if(!$stmt = $mysqli->prepare("INSERT INTO clients(fname, lname, orgName, address, city, state, zipcode, phone, fax, email, confirmEmail, projectOptions, projectOverview, year) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)")) { $sql_errors["Prepare"] = $mysqli->error . PHP_EOL; } else { if(!$stmt->bind_param('ssssssiiissisi', $_POST["fname"], $_POST["lname"], $_POST["orgName"], $_POST["address"], $_POST["city"], $_POST["state"], $_POST["zipcode"], $_POST["phone"], $_POST["fax"], $_POST["email"], $_POST["confirmEmail"], $_POST["projectOptions"], $_POST["projectOverview"], $_POST["year"])) { $sql_errors["bind_param"] = $stmt->error . PHP_EOL; } else { if(!$stmt->execute()) { $sql_errors["execute"] = $stmt->error . PHP_EOL; } $stmt->close(); } } $mysqli->close(); header('contactTest.php'); } ?> <!doctype html> <html lang="en"> <head> <meta charset="utf-8"> <title>Untitled Document</title> <style type="text/css"> .error { color: #FF0000; } </style> </head> <body> <?php if(isset($sql_errors) && sizeof($sql_errors) > 0) outputErrors($sql_errors); ?> </body> </html>

Yeah, I dislike the enum type myself. First off, it's not standard SQL, so it's only supported in a handful of DB's. I think you should have a really good reason to use an rdbms specific implementation. Secondly and much more importantly, you are mixing DDL/schema definition with "data". The decode values for the internal enum representation can just as easily be done as a separate table with a foreign key relationship, and you at that point don't need to allow updating the actual table definition in order to add or delete from the enum list. I find that people are of one of 2 minds: 1. I want everything relational, and configurable through the db. If that's the case then use a separate "lookup" table and relate it using the foreign key. You can minimize the storage cost in mysql by going as granular as a char(1) or a tinyint. You also have the benefit of using foreign key constraints for data integrity, while still allowing an admin system to add new values. 2. I want my code to drive this, so that I can reduce load on the db. Often people will have a list of constants, perhaps in an array: $shirtsize = array('s' => 'small', 'm' => 'medium' 'l' => 'large' 'x' => 'extra large' ); This is all an enum is doing for you, and if your argument is that you don't want to pay the price of having an actual legitimate relation by foreign key, then this is often better represented in the server side code, where you can then do things like string localization, and where the enum doesn't benefit you. It seems like your question is in regards to how you update the list of allowable values for the enum, and the answer is -- you have to alter the table. As I said originally, you don't want to do that, because you really don't want your application to even have the rights to do DDL calls that can add tables, drop tables or alter their structure. A glitch or an exploit and your whole database can easily be zapped by an attacker. Also altering a table requires it to be locked which limits concurrency and uptime for your app. If I'm not understanding your question correctly please elaborate, but my advise would be to avoid using enums, since you have several simple and standard options that allow you to do what you need to without them.

First I'd suggest moving your function display_form() { .... } code to the top of the script right after your other function declaration and before your actual script logic code. Re-run ad check your error logs and see what they are telling you.

Hi NotionCommotion, Just to clarify what you are doing, albeit for ostensibly understandable reasons, is one or both of "spoofing" or "relaying" which are considered highly undesirable by spam classification systems. They also, depending on the implementation, open your site up to blacklisting, because nefarious individuals often exploit these features, which used to be common but are now considered a "really bad idea" to send spam, using your systems. So first relaying: When you are the Mail transfer agent (MTA) for a domain or even several domains, that is something that is configured in DNS, in your MTA settings, and typically has SPF and DKIM settings wired in. These are things the sysadmin configures, and there are also reverse DNS settings that come into play. In summary, the only emails your MTA is supposed to send on your behalf are emails from [email protected]. If your MTA sends out emails or relays emails from [email protected], then you are "relaying" emails for that domain, and that is not supposed to be possible, and is an exploitable problem that degrades email for everyone. That will get you on blacklists. I'm not sure how you are sending out emails, as it is possible to send them directly from an app server, but that is also a great way NOT to get your emails delivered. Sure they will go out and even be received by some sites, but many more will blackhole your emails (receive and silently delete them) or grade them with high spam scores that are sent to the end user's spam box. You can also again, get your site on blacklists for doing this. You should only send email out via a valid MTA for your domain! Many sites also, often by necessity use remailing services, especially if they are hosted on cloud services, as many of these services (AWS for example) severely limit the number of emails that can be sent out of their network directly via SMTP protocol. The one trick that people often try and use to get around the problem without entirely violating the rules and spoofing the from address, is to send emails out as a valid user for your domain, but add the "from user" as the reply to email header. I know that's not what you're trying to do, but is about all you are typically allowed to do without raising your spam score to the "this is spam" level of most classification systems. I know this is not what you wanted to do, but you simply can not spoof a from address and send it out of your domain and not suffer repercussions that will at very least have the majority of your emails going into the receivers spam box, or more often than not, simply rejected or silently deleted. This is because spoofing from addresses is harmful to the email ecosystem at large, and is a huge red flag for spam classification systems. It can also cause the receiver's system to erroneously spray error replies to domains that had nothing to do with the email, not to mention the fact, that inherently you are not able to prove to anyone that the email address you are claiming the email is coming from, is actually the person who owns the email in question. This is one reason why the good old html mail tag causes the browser to invoke the user's configured mail client, so that they can send emails out through their own system as it is the only way to legitimately do what you're hoping to accomplish, and have it taken seriously by the receiving email systems. Sorry to be the bearer of the bad news, but the bad people ruined email for the rest of the world a long time ago.

No, sure isn't. Keep in mind you can always use the php.net site. It supports a rewrite for every function via http://php.net/function_name. So for example: http://php.net/date_format Worth trying when in doubt.

Do you have code that generates the gif(s)? That would be the first step I would think. You'd have to clarify what you're trying to do. If it's a wall spamming app, that's not possible anymore afaik.

^^^^ Seems pretty clear that there isn't a display_form() function defined anywhere that this script has access to call.

Responsive design required a few technologies and techniques to mature before it became pervasive. Initially, adaptive was the simpler, albeit brute force technique of choice and large companies had the resources to create essentially multiple specialized sites, and the technology of user agent detection and classification has been around for a long time. At this point, it's more economical to go with a responsive design, not to mention far less resource intensive in regards to maintenance. I would expect to see adaptive sites die off over time, but like any design trend that goes hand in hand with standards and browser support, it will take some time, and you'll still see large sites that will not see the need to change something in the short term that takes care of the critical need simply to stay current, but will probably change when there are strategic reasons like the desire for a fresh design that offer the opportunity to update the underlying code base.

global variables as in the type illustrated in your snippet have not been changed at all. I find the name somewhat misleading for many people, because any variable in PHP declared in the "script" scope, is global. However, unlike many other static languages, global variables are not visible inside of functions. Thus the global keyword simply makes an existing global/script variable available inside the function, as in your example. Register globals is a long deprecated and highly insecure feature that when turned on, will automatically make all user and server supplied variables into individually named global variables. This would allow an attacker to attempt to manipulate your apps by calling scripts using lists of get or post, or cookie variables they supply. It has been turned off by default literally for years, and you should not have been using it. If in fact your app is broken for this reason, you should fix it. The superglobals like $_SERVER, $_GET, $_POST etc. exist to provide you user input and url parameters. In general, you can pass variables into your functions, rather than having long lists of globals, but even if you don't fix that, at least make sure you fix the register_globals related code, by finding those places where your code was relying on that, and getting the values from $_GET or $_POST.

It really depends on the capabilities of the Model system you are using. If it was for example, something like Symfony2 and Doctrine2, the typical answer would be that the validation rules are attached to the model. Of course with that said, form processing rules can get quite complicated, and since the form object lives and dies inside the controller, you will typically have the actual validation check occurring specifically in the controller logic. Something like: if ($form->validate()) { // Persist the data // Redirect as desired } else { //redirect back to form, adding the error data }

I'm not going to go into the "which is best" question. The answer always depends on a lot of variables that are typically unique to the circumstance. Obviously c++ is often used for compiled software, and java is often used due to it's availability on a platform (Android for example) or in the enterprise where one or more application servers are desired. In my experience, for server side web development, Python, Ruby, PHP, Java and Node.js are all popular choices that typically come down to the preference of the Lead developer. In terms of intermixing languages, specifically with PHP one popular way to do that is to use Gearman. For example, I worked on a project where there was a computation engine written in Java. The website MVC and additional computation and presentation code was created in PHP using a popular PHP framework. PHP utilized gearman to send data to the Java computation processes as needed (this had to do with crunching large amounts of historical stock price information) and received the results back for presentation within the PHP framework. You can also build your own queueing sub/pub applications using many different technologies, and achieve similar separation of work. This type of architecture is frequently used where scalability is a significant concern. An example might be a system like Youtube, where the video encoding or post processing is going to be separated from the front end, and clustered. The clustering and DevOps scaling will be separated from the web application code, and since processing of that type is cpu and IO intensive, you won't have that code running on the same server(s) where the PHP code resides.

We'd have to understand what you are trying to do. Are you simply trying to get the counts? SELECT Local, COUNT(*) as countof FROM MEMBERS GROUP BY Local You get 2 rows in the result, with the count of Local true vs false.

Good luck with your legal action.

We don't know what your database structure looks like. Are we to assume that this query is the one in question? select * from updates where account_name=:either and type='a' or account_name=:either and type='c' order by time desc limit 20 You mention ID, but then you query for account_name? Is account_name the ID? You should verify what is being bound to the query in the :either variable. You can also simplify your query using IN. select * from updates where account_name=:either and type IN ('a', 'c') order by time desc limit 20

Emails are going out. With that said, we have no control over whether or not your email system receives them or delivers them. Often emails like these get classified as spam.

You should start with an understanding of the difference between a hash and encryption. This site hashes passwords and stores the hash. What this means in a practical sense is that we do not store the passwords. Nor can they be decrypted. People who are interested in this subject can do additional research. We have had ample threads discussing this for years. As further stated, we use a well known commercial forum software package here. It was stated clearly, but anyone who wanted to even look at the forum for a minute would be able to tell that this is the case and we did not "roll our own cryptography". Given that you failed to understand these simple facts that are basically self evident to any reasonably knowledgable developer, you're either trolling, or not the sharpest tool in the toolbox. One of our staff believes that you may have simply glossed over the basics. This is a community where experienced developers have helped others with PHP for a long long time, and while you're clearly unfamiliar with what we've done for something like 14 years (long before SO and most of the other well known developer forums) that doesn't excuse the fact that you've rushed to judgement and made assumptions that were just wrong. Quite frankly, with decryption, the requirement is that a decryption key exist. These keys are likely to be compromised if your site is compromised. A hash has the advantage that it intrinsically is not decrypt-able. This is a judgement call. Anyone who used a well formed highly random password has very little to worry about because their password will not be in a Rainbow table, and that is/was the case here.

Hey R0CKY, I will repeat things for the benefit of anyone else like you who is unclear in regards to assertions about the Admins of the site. We are not paid. Never have been, never will be. We volunteer our time. This is not our top priority. We don't own the site, and have minimal control over certain aspects of it. Yes there are Ads, and this revenue goes to the guy who pays for the infrastructure, bandwidth and hosting. At a time like this, it's not really all that important, but people can make their own decisions as they see fit given the circumstances.

We think we have an idea of what happened, and we've been spending time looking over our servers. We will not have certain types of forensics to guarantee a postmortem, but even if we did, I don't know that we would post it. We have identified a particular individual and actions they took within the forum software itself. I previously made a statement that suggested it might have been caused by a weak admin password, but after more research, it looks like the problem was actually related to security holes in the forum software. Wit that said, I don't want to offer opinions, and simply stick to the facts. We can not and will not warranty or guarantee anything, and we have a TOS to that effect, which is no different than any other site out there. The staff donates their time to run a site that for over a decade has provided the PHP community with free programming help and advice. It really speaks for itself that it has managed to do that effectively for over 14 years. I can't speak for the entire staff, but if the risk to be here outweighs the rewards, we will advise people of that fact, and in all probability we would shut the site down rather than allow it to be compromised repeatedly.

It's pretty much common knowledge that this site is run by volunteers. None of us are owners. The site uses fairly well known commercial forum software. We did not write it. The password file is salted and hashed but that will not prevent someone who is highly motivated and has sufficient computation power available to crunch combinations. Passwords will always be a significant issue. In short, this is a non-commercial venture with limited resources. Of course I could point out that large enterprises with millions of dollars of security hardware and networking infrastructure to support it, as well as entire security staffs have been compromised, but I'm sure you know better than them. Last but not least, spam registrations and the degree to which that is possible here is a tradeoff. We have dialed things down in the past to the degree that legitimate users were discouraged from making accounts. We've decided to open things up and make it simpler for them and for this reason we have to do with a relatively small degree of spam that is cleaned up fairly quickly. It has nothing to do with security or system administration.

Obviously we don't want to go into additional detail, but the passwords were salted and hashed multiple times.

To elaborate on Jacques comment, PHP is a loosely typed language the does all sorts of type casting on the fly. You can try this for example, and you'll get a very different result than the one you got in your example, where php was working with a string type internally. <?php $v = 77; echo $v . "\n"; echo $v[0] . "\n"; echo $v[1] . "\n"; echo "Done\n";

It has come to our attention that someone managed to get their hands on a database dump of the phpfreaks members table used in our forum database. We apologize for the inconvenience and concern this may cause you. *UPDATED* Based on research, we believe that the individual(s) responsible utilized some exploits available in the forum software that allowed them to run a php script that dumped the data from the forum user table. While the passwords are hashed a number of time and in many cases salted, someone who is highly motivated to do so, may be able to derive your original password, especially if you did not use good password practices. A hash password can not be decrypted, but by generating rainbow tables, crackers can determine if your password matched one of many they may have in a database. The table also includes your name, so it may or may not associate you with the email address you used to register. We highly recommend that you take the following actions: 1. Change your password 2. Change the password on any system where you used the same account name/email/password combination. 3. Use unique high/quality passwords on any and all systems you frequent now and in the future. Should we make any additional determinations or discoveries in relation to this issue, we will provide updates here. *PLEASE NOTE* We will not be deleting accounts upon request. We stated that we would not delete accounts for any reason in our TOS when you signed up. Deleting accounts is not going to retrieve the user table data.

Sorry about that, I killed the backlog, but not before it sent out a lot of stuff while I was still debugging.