CakePHP 2.x | Console | cake bake all | Windows + Linux

In CakePHP the “cake” (console) command can be used to bake scaffolding Model, View and Controller files (to quickly create content management system).

Following is the command
“cake bake all”

“cake” is the actual command.
“bake” and “all” are parameters (other options are available to selectively bake stuff – M/V/C).

“cake” is the Linux shell command.
It will not run on Windows, because it is a Linux shell command.

To run this on Windows you will need to use cake.php (available in the same folder – app/Console).

Since, by default, php path is not available in command line, so you will need to provide php path also.

So, the final command will be something like following:
(assuming, XAMPP is installed – and, you are already in c:\xampp\htdocs\cakeproject\app\Console)

c:\xampp\php\php.exe cake.php bake all


Basic Linux shell commands for new users

touch a.txt (to create a new blank file)
ll (to list all the files in this folder)
ll | grep john (to filter the files matching the pattern – john – in this case)
ll | grep tac

chmod 0777 test_file (to make the file fully writable for all users – not recommended for production environment)
chmod 0777 test_folder (if this is a folder, then the permissions are set for this particular folder only)
chmod -R 0777 test_folder (Applies the permissions to all the folders and sub-folders inside this folder)


Model based DB understanding

There is a need of paradigm shit in terms of database modelling.

The shift needs to happen at the relationship level – instead of using tables, the relationships should connect at the Model level.

This is a major shift, and requires a different mind-set altogether.

Models should be considered while designing the application (architecture).
Tables should(would) come into picture only after the conceptual Model have been created and the relationships have been clearly identified and specification for that has been set (and rightly so).

More on this later.

coding, jakaildesignspegh

Tapping the core coder within me | NOW

It’s been a long time since I have written a code of the level that I was kinda proud of.

I think I need to tab in to my oracle grid, and access the projects Pegasus, Exodus and Goliath, and bring in the core coder again (#IronMan reference).

My typing speed has slowed down ever since I have stopped coding, my creativity has started to die and my estimation skills are improving (that is a sad thing to happen if I want to continue to call myself a coder – usually my estimations fall back by approx 5-10 times).

I am trying to access a lot of my brain’s part to work, and I am hopeful to get this done since I have started to get on to a artificial add-on : mod(alert)

Coding on RedBull right now.


coding, jakaildesignspegh

Just another day in paradise

Woke up, coded for half an hour on IMS(Inventory Management System) that I and Bal are working on, opened up the gift from the company I’m working at(Trantor), and now on way to drop the wife to her office.

Planning to visit Peacock Garden(Chandigarh) with mom and daughter, and later check few creches for the kiddo to start her pre-schooling.

Also plan is on the table for an evening at Dharampur.



OpenCart v 2.x review of Authentication SQL

OpenCart v 2.x [Full version =]
[Also applicable on previous versions (2.x series only) and will probably prevail for near future updates in 2.x series]

OpenCart saves password in a 40-bit length field name in (prefix)user and (prefix)customer table, along with a 9-bit salt value, in the adjoining field, which is good.
The login check involves 3 cycles of concatenating the salt with SHA1 hashed password, which is also ok.

However, in the SQL for the login check, there is an alternate option to check for a valid password(with an actual OR statement) by simply checking MD5 hash of the password.

This is a strange behavior, and may have been introduced to add some kind of backward compatibility (which I am not sure is the actual cause, due to my lack of understanding of previous versions of OpenCart), but this *should* not have been done.

What this means is that if someone is having access to your OpenCart database, and the attacker simply updates the password field with the MD5 hash, the password will work for admin user as well, and the salt would not even be part of the equation.

If the OR part of the SQL would have been dropped, then even direct access to database would have prevented any attacker to get hold of admin access by directly changing the password to MD5. The salt would also be needed to be updated, and a (small) layer of security could have been added.

Actual SQL (final) that is generated by OpenCart:
// For Customers
“SELECT * FROM oc_customer WHERE LOWER(email) = ‘” . $this->db->escape(utf8_strtolower($email)) . “‘ AND (password = SHA1(CONCAT(salt, SHA1(CONCAT(salt, SHA1(‘” . $this->db->escape($password) . “‘))))) OR password = ‘” . $this->db->escape(md5($password)) . “‘) AND status = ‘1’ AND approved = ‘1’ ”

// For Users
“SELECT * FROM oc_user WHERE username = ‘” . $this->db->escape($username) . “‘ AND (password = SHA1(CONCAT(salt, SHA1(CONCAT(salt, SHA1(‘” . $this->db->escape($password) . “‘))))) OR password = ‘” . $this->db->escape(md5($password)) . “‘) AND status = ‘1’ ”

The highlighted part is the one that should have been avoided.