gizmola

More mysql syntax nonsense. Even if it's valid let's pretend it isn't and just use the standard syntax that all other RDBMS's use.

Just out of curiosity, why would it take so long to get an answer on your db access? Here's the way mysql security works: First you have users. The form of a user name is sort of like an email address: user@hostname So to begin with, it is possible to have something like this: user@foo.ourdomain.com or user@30.232.33.15 When you run mysql on the same server, users are typically constrained as: user@localhost This means that only someone attempting to attach from the same machine (via localhost) will be given access. If you want to understand this better you can google for "mysql GRANT" which is the SQL used to create a user and grant them access to a database. Again, knowing nothing about your hosting company, they could have a mysql server that is on a different machine. This is easy enough to determine from the host string instructions that show up in your control panel. If you're connecting to a remote mysql server (or more specifically, if your php script is connecting from the hosting machine across their network to another box) then the specifics of that connection have to be configured correctly. So it's possible for you to have a user where due to issues with IP's or DNS names internal to their network, had access but now is being rejected. There are a number of different problems, and really only the hosting company can do much. However, it wouldn't hurt for you to write a simple connect script that tried the connection and then returned the specific mysql error. <?php $db = new mysqli('host', 'user', 'pass', 'database'); if ($db->connect_errno > 0) { die('Unable to connect to database [' . $db->connect_error . '] - Errorno:' . $db->connect_errno ); } else { echo 'Connected ok'; }

Make sure all your servers are setup to use GMT. When storing a timestatmp or datetime in a mysql database, I wrote about this topic extensively here: http://www.gizmola.com/blog/archives/93-Too-much-information-about-the-MySQL-TIMESTAMP.html As long as you don't need to store future or distant past date time values beyond the range of the timestamp, then timestamp is the most efficient type. I cover all the ins and outs of what timestamps do for you automagically in mysql, and how to enable or disable that behavior. For example, by default the first timestamp in a mysql table will be updated when that row is inserted or updated. Timezone is a user attribute or preference. You should store a timezone preference in the member/user/profile row. From that point, you can easily read the original GMT timestamp value into a PHP Datetime object, and apply their timezone to it, and then display the value to them in their timezone. This is all covered in the documentation for the php datetime object. To generate the list of timezones: $tzlist = DateTimeZone::listIdentifiers(DateTimeZone::ALL);

In my hurry to answer I glossed over the fact that you changed the syntax, but maxxd is exactly right. Go back to your original syntax, and just tweak the original code with the bind variables, and everything else is the same. Insert statements use the INSERT (column,...) VALUES (:bind1,...). Update statements use the SET column = :bind1, ... etc.

You don't need to worry about the links: just read the session variable in your serverside script as in the example I provided. The code I didn't provide is the one that sets the variable when the user uses your form to change it. In a nutshell it's no harder than: $_SESSION['category'] = $_POST['category']; I don't want to muddy the picture, but like all routines that accept user input, you should validate the input, so I omitted that for simplicity purposes. In summary, once you are using sessions, you no longer want/need to pass the variables as url parameters. This is cleaner and nicer for your users anyways.

CakePHP and Codeigniter served a purpose in their day. With that said I'm not a proponent of using really old frameworks like these, when there are plenty of modern alternatives out there. With all due respect to cakephp, 3.0 sets a low bar when frameworks like symfony2 have been doing all the things that 3.0 is "Trying" to do, for years now. Cake had its day, but time has passed it by. I would think that most cakephp development these days is done by people supporting older projects, and someone doing a new project in any version of cake, not to mention one that is based on an alpha framework release, is completely insane. Some good relevant ones worth looking at: symfony2 laravel zend framework 2 There are also so-called micro frameworks like silex and slim that might work for you. Personally, I think your investment in learning how to be productive with a framework is substantial and you are best off choosing one that has a substantial user base, a vibrant active community and good documentation. You have to investigate all these to get an idea of what makes sense for you.

Much better now. It does appear that the Message date is most likely the issue. To verify, comment that out of the sql and params list and see if the statement works ok. What is the type of that column in the database?

Provide us a var_dump of your $json variable please. It doesn't seem to jibe with your example code.

Ok I see you just replied -- try out sessions and let us know if you have issues.

You can pass the variables as get parameters, but they will already be hard coded into the returned html. At that point it is too late to change them other than to use javascript. You also have the same problem of retaining those settings across pages (user sets his location, but now he's on different page -- and it forgot his location. Session variables are the answer. What is it about the info we provided that you don't understand?

Hi Eldan, At the top of your class file you establish that the namespace is lesson_one. This means that until such time as you change namespace, you are working in the lesson_one namespace. Thus it makes no sense that you would refer to specific names paths later in the same file. If you're including that in a script, then the namespace specifier would make sense. Also, as Kevin pointed out, Autoloaders make all of this detail superfluous, and you wouldn't use the namespace to access those either, because they'd be autoloader and available typically with the "use" keyword.

What do you want us to do for you? It's outside of the scope of this forum to modify a commercial scripting package (phprunner) assuming such modification is safe or advisable. It sounds like you're an end-user and not a programmer. I'm by no means trying to run you off, but this is a community to help programmers, students and hobbyists, and even business people who are trying to modify existing code. With that said, you have to do the heavy lifting -- otherwise it's just programmers doing work for people for free, which is not what this forum exists to do.

Pretty much what fastsol said -- this is what session variables are made for. When the user selects those drop downs, you set them up as session variables. Then have your subsequent scripts include an include file that has simple code like this at the top: session_start(); $category = isset($_SESSION['category']) ? $_SESSION['category'] : 'Some default';

Just for comparison here are a couple of good/heavily used validation libraries to compare and contrast yours with: https://github.com/symfony/Validator http://framework.zend.com/manual/2.2/en/modules/zend.validator.html

The class has a private variable $_errors which is an array where error messages are added when validation fails. Private variables are only visible inside an object of the class. They can not be seen or accessed outside of the class itself. So for that reason the class has a class function errors() that returns the contents of this private variable. This is why the code you have should theoretically work: if ($validation->passed()){ echo 'passed'; } else { foreach ($validation->errors() as $error){ echo $error, '<br>'; } } Your code was missing the end block but I assume that was just a copy/paste mistake. The problem with the code you provided is that I don't see where the $_passed variable gets set to true, but I will assume that it actually works somehow, perhaps by checking the contents of the $_errors array? If that's the case, there is no reason for the $_passed class variable to exist from what I can see. Doesn't seem like the best validation class?

In your list of columns, you don't include MessageDate, however you pass the date as a parameter in the values. You also have some bind variables in there with some regular values. You should only have the bind variable names. $userid, :recipient, :subject, :cc_email, :reply, :location, :stationery, :ink_color, :fontchosen, $messageInput, :attachment, $date $userid, $messageInput, $date --- these should all be bind variable names, not the variable values.

Hey Tony, Yes, I didn't want to get into all that backward compatibility crap, as I think it only adds to the confusion, so I left it out. You make a good point about the plugins location, and I have to assume that a "composer supported" cakephp would need some special configuration that would add its directory to the number of searchable paths. I know that you and I are in agreement that we avoid the old pre-5.0 frameworks like Cake and CI, and I never cease to be amazed by the fact that we seem to get more questions about them then we do about any of the frameworks we actually like and use.

Hi evansste, Security is a very complicated subject. In my experience, and unless you have some enemies out there targeting you, it's highly unlikely that someone would spend the time to try and exploit your specific site. Most attack vectors are automated, and the exploiters are not interested in your specific system. Typically exploits attack some known weakness of the operating system or a specific package you might be running like wordpress or joomla or phpbb. Scripts you run that you otherwise don't understand would be the most likely culprits. You currently don't have enough information to even determine that your password was changed. That's an assumption that could be entirely incorrect. We could all conjecture until the cows come home, but I find it unlikely that someone would exploit your site with the specific goal of changing your mysql password which only serves to tip you off that something has changed. Really, your specific hosting setup is the first thing someone would need to understand. There are bad shared hosting setups for example, as alluded to previously, which make it easy for someone on the same shared host to read all the files in your webspace, but I find it hard to believe in 2014 that there are too many shared hosts who still run those types of setups. For the most part, they implement fastcgi and insure that the apache process(s) run as your user, so that those types of "trusted user" exploits aren't possible anymore. For all we know they had a blip in their setup or someone screwed something up so that you can't attach to their mysql server as the same user anymore. If you did have a sql exploit, they might also have dropped your entire database (if it's an especially malignant and destructive bot) but again, that is not the goal of most exploitations. What they want is access to your resources, typically to run programs, store files and serve them (leeching your bandwidth) or send spam email through your server. All this is automated. In order to get what they want, they have to be able to control their botnet, and often this is done through IRC channels, so a telltale sign of compromise is that they setup outbound irc connections to their control channels. Sometimes their scripts screw up, but changing a mysql password is just something these exploit scripts wouldn't do intentionally. Only someone with root access is going to be able to probe and figure out what exactly has gone on with your server/instance etc.

When you send variables between scripts, you have these options: -Get parameters -Post parameters -Cookies -Session variables. In form2.php you get the return of your form, and you set these to php variables, but when the script is done running all those variables are discarded. If you really want to continue with this 3 script structure, probably the easiest way would be in script 2 to set your form with a corresponding number of hidden form variables with the same names. Then your current structure will work basically as expected. So one example would be: <?php $fname = $_POST["fname"]; ?> <input type="hidden" name="fname" id="fname" value="<?= $fname ?>">

Just FYI SQL Anywhere is not SQL Server. It was originally a product from Watcom that provided a small scale rdbms focused on data replication. It was designed for small shared sql databases that needed to be replicated potentially across wan's and possibly hundreds of servers. It is often licensed as an embedded database for small scale sql db needs, being that it has a lightweight engine process that has been ported to a lot of different platforms. It's not surprising that a company might have built a product with it embedded. I don't know that we're clear on your requirements. What does "make it publicly available" really mean? I'm guessing here that what you mean is that you are going to have to develop an extension to your website that does queries to the sql anywhere database. Assuming that is true, and because sql anywhere intrinsically has this replication capability, one option is to run a sql anywhere instance on your linode box, and then all you would want or need to do is allow just enough access through your firewall for the replication traffic to run between your internal box and the linode instance. You could tighten these rules down to the specific ports and ip's with port forwarding and deny/allow rules. You would not need nor want to put the box in the DMZ. I'd really want to fully understand the vendor's solution stack before I made any decisions on this, so consider it food for thought, although you can run this idea by them, again assuming that their system is built on top of sql anywhere.

Vagrant is a popular solution for all these problems. With that said, composer does do much of the heavy lifting. With vagrant, and some puppet or chef configuration files, you can have complete self contained virtual machines you can start or stop as needed. It automates the creation of a VM and all the initialization can be automated. What I really like about it among other things, is that it keeps all that configuration in a shared-nothing environment -- so if you need a complete vanilla LAMP environment with a basic cakephp environment, you could set that up, and tomorrow if you need a 2nd environment, you can simply use the same vagrant file. You do need a fairly beefy machine with plenty of available memory, but Vagrant has packaged and simplified most everything else. For example, I found these 2 vagrant files to look at: https://github.com/FriendsOfCake/vagrant-chef https://github.com/rehabstudio/vagrant-puppet-cakephp From what I saw there are many more to investigate. Just to be clear, if you had vagrant setup on your workstation, you could grab one of these vagrant file projects, copy the structure to a new project directory you make, change to the directory and vagrant up, and you'd have a full working system where you could iteratively work and develop new code.

Just to clarify, Composer files have to be in json format. So you need a composer.json file, not a composer.js. It is json, not javascript code. Aside from the location of the file, a library really needs to be in a public version control system. The way dependencies work, and for the ongoing development of the library, the author already needs to be somewhat savvy as to how to version the library. You don't for example only want to have a master branch, and have everyone pulling the library from master, if you will be actively updating it, perhaps with new features or changes that will break the old functionality. For that reason, ideally the author should already have a release branch and have version tagged it appropriately. This information all goes into the composer.json file. More about setting up a library is in the composer manual: https://getcomposer.org/doc/02-libraries.md The library also needs to be PSR-0 compatible. See: https://gist.github.com/Thinkscape/1234504 PSR-0 insures that libraries will be setup in a structure, and to have used php namespaces so that there won't be collisions, and that composer will be able to build a valid autoloader to make the use of the library functional.

SF2 is a dependency injection framework. It's probably a reach for you to expect to understand DI when you don't grasp the basics of oop. These days, the state of the art in PHP is component libraries, thanks to composer. You need to get it installed and learn the basics of it, if you want to bring yourself into the modern era of PHP. I should point out that Laravel's core is the symfony2 components. With all due respect, are you really in a position to judge the benefits of OOP? I understand if a master coder who can use OOP fluently wants to rail against it, but someone who admits they don't yet understand the basics of it, isn't really in a position to dismiss it. Take the time to watch this video, and it should help you understand why Composer is important, and why component libraries are the state of the art in the PHP world (and why this was a long time coming and absolutely necessary for PHP to continue to compete with alternatives like node.js, python and Ruby). Here's a 2 minute video on namespaces which are important to understand when using libraries and modern PHP OOP: https://knpuniversity.com/screencast/php-namespaces-in-120-seconds/namespaces Here's a 14 minute video on composer: https://knpuniversity.com/screencast/composer/composer After you have watched these videos, I hope you'll start to gain some clarity. After that you'll be in a position to begin to untangle frameworks (which are really a set of interdependent classes), and you might even be inspired to start to play with some of the individual symfony2 components. Try making a simple project that utilizes one or two components and just write some simple code. A great one to start with for most people is: http://symfony.com/doc/current/components/finder.html For example, you could write a simple script that uses the component to find all the files in a particular directory (and it's subdirectories), sort by name and list the files out. Try it with the special $finder->in(__DIR__);constant __DIR__ which will be the directory where your script is located. With the component, it is literally something you should be able to write in 10 minutes or less, using only a handful of lines of code.

SQL injections are basically a situation where the user is able to "inject" a modification to the SQL statement via input. Here's a simple example: $sql = "SELECT * from MEMBER WHERE account = '$account' AND password = '$password'";This is a somewhat typical login statement, where someone will provide their account name and password to a form, and you accept input and build your sql statement. Then based on the return of a row, people will often accept the login as valid and set the user's session variables with the account information. BUT!!!! What if the user sends this as input --- ' OR '1' = '1 Now when the password variable gets interpolated the SQL string becomes something totally different than what you originally intended. For this reason, you typically have to be extremely careful about escaping input variables so that these types of injections can not get into the code. It's just much simpler and safer not to have to deal with escaping at all, and instead, to use prepared statements with bound variables anyplace where you're going to take user input and use that as the basis of a query, whether that be a select or an insert or update.

Yes, but between is the same as WHERE t.foo >= {low} AND t.foo