[Deprecated] DMZ 1.5.3 (DataMapper OverZealous Edition)

[eluser]OverZealous[/eluser]
[quote author="xt3rm" date="1253564530"]I just have one question, is it possible to use the 'htmlform' extension to generate the input forms for related fields?[/quote]

HTMLForm isn't very well fleshed out. Currently it acts as a sort of simple scaffolding tool. I have plans for it over time (including adding related items to the fields), but currently there is no built-in way to do this.

[eluser]OverZealous[/eluser]
[quote author="Jinkusu" date="1253570475"]i need to access the list of subjects from the as far as the Programme table so for each subject their is one course. hope i'm not being to vague.[/quote]

I'm sorry, but I don't understand what you are asking here. Can you please re-word the question?

Thanks!

[eluser]Jinkusu[/eluser]
Its OK, i already solved it. Thanks anyway!

[eluser]jcavard[/eluser]
Hey!
I am struggling with a created field. Has anyone ever stumble across this error "Incorrect datetime value"? Why is there +0000 at the end of the field? The table structure is fine, the field is DATETIME NOT NULL. Where is this +0000 thing coming from?

Code:

Error Number: 1292

Incorrect datetime value: '2009-09-22 16:59:34 +0000' for column 'created' at row 1

INSERT INTO `searches` (`created`, `loan_amount`, `amortization`, `payment_frequency`, `mortgage_payment`, `interest_paid`, `principal_paid`, `total_term`, `outstanding_balance`, `rate_id`) VALUES ('2009-09-22 16:59:34 +0000', 7701933333333, 300, 'ddd', 44927944513.21, 1234.44, 9873.2, 33.33, 9999.33, 1)

[eluser]OverZealous[/eluser]
[quote author="jcavard" date="1253657075"]Why is there +0000 at the end of the field?[/quote]

That's the timezone. It's is part of the standard, ISO accepted formats for timestamps. Either you live in the GMT/UTC time zone, or your server is incorrectly configured, which is why you see a TZ of +0000. Mine, for example, is -0500.

If your database cannot accept timezone values, you'll have to manually change DMZ (this is going to be a configuration option in the future). Open libraries/datamapper.php, scroll to the save function, and change the two occurrences of 'Y-m-d H:i O' to 'Y-m-d H:i'.

[eluser]jcavard[/eluser]
[quote author="OverZealous" date="1253668186"][quote author="jcavard" date="1253657075"]Why is there +0000 at the end of the field?[/quote]

That's the timezone. It's is part of the standard, ISO accepted formats for timestamps. Either you live in the GMT/UTC time zone, or your server is incorrectly configured, which is why you see a TZ of +0000. Mine, for example, is -0500.

If your database cannot accept timezone values, you'll have to manually change DMZ (this is going to be a configuration option in the future). Open libraries/datamapper.php, scroll to the save function, and change the two occurrences of 'Y-m-d H:i O' to 'Y-m-d H:i'.[/quote]
you tha man!
thanks!

[eluser]cahva[/eluser]
Hey,

Im using the login_manager from the example app. Theres a "tiny" security flaw in there as it will pass validation with correct existing username but no password field at all.

I noticed this when I made my own login page, but had spelling error in the form with the password field(password input's name was different).

I know you made that login example just as an example but just wanted to inform this if someone else makes the same mistake or is taking your login_controller/user model as a basis for auth.

For a quick fix, I just changed this(in the login.php controller):

Code:

if($this->input->post('username') !== FALSE)

..to this:

Code:

if($this->input->post('username') !== FALSE && $this->input->post('password') !== FALSE)

If this has been spotted earlier in the posts, my bad

[eluser]OverZealous[/eluser]
[quote author="cahva" date="1253670941"]Theres a "tiny" security flaw in there as it will pass validation with correct existing username but no password field at all.[/quote]

You've changed something from the example code.

First, you have to make the password field required. If it is required, you should get an error.

Also, from the example page:

Code:

// A login was attempted, load the user data
$user->from_array($_POST, array('username', 'password'));

Notice how the code explicitly sets username and password. If you don't explicitly set the fields, then of you will certainly have a security hole, such as this:

Code:

// INCORRECT: the from_array code will only set those fields that are passed.
$user->from_array($_POST);

The way the example code is written, it won't succeed if you type in an empty password, or a hacker submits the page without a password. (I just tried the latter.)

I did, however, get a Database error when submitting with just a username (for trying to compare 'password' with the number 0). But since you have to be trying to break stuff, it's not really a bug.

[eluser]cahva[/eluser]
I have it the same in my code:

Code:

$user->from_array($_POST, array('username', 'password'));

User model's validation is straight from the example application (minus the bug relations)

Code:

var $validation = array(
        ...
        'username' => array(
            'label' => 'Username',
            'rules' => array('required', 'trim', 'unique', 'alpha_dash', 'min_length' => 3, 'max_length' => 20)
        ),
        'password' => array(
            'label' => 'Password',
            'rules' => array('required', 'trim', 'min_length' => 3, 'max_length' => 40, 'encrypt'),
            'type' => 'password'
        ),
        'confirm_password' => array(
            'label' => 'Confirm Password',
            'rules' => array('required', 'encrypt', 'matches' => 'password', 'min_length' => 3, 'max_length' => 40),
            'type' => 'password'
        ),
        ...
    );

If I remove the password field completely from the form, it will pass the valdation(if user exists in the users table). Are you saying that it should give error already with the from_array($_POST,'username','password') ? Well it doesnt

I just checked the code and there really is nothing more changed than a) I dont use htmlform extension, just plain login form. b) redirects point to another controller on succesfull login(not welcome page).

[eluser]OverZealous[/eluser]
@cahva

I tested attempting to load the user without sending the password, and I get a query that looks like this:

Code:

SELECT *
FROM "users"
WHERE "username" = 'phil' AND
      "password" = 0 AND
      "salt" = 'b1fdefd520ccfcea4d8c9edfa5bfb775'
ORDER BY "users"."name"

That code should not return a row. It doesn't in my test application. (On Postgres it returns an error, but I tried manually querying with password = '', and it still failed.)

Make sure you are running the latest version, including making sure that the array extension is up-to-date (although I don't think anything has changed in a while). I would check the generated queries, as well.