[Deprecated] DMZ 1.5.3 (DataMapper OverZealous Edition)

[eluser]tdktank59[/eluser]
[quote author="OverZealous" date="1251935081"]
@tdktank59

I always code in short tags (JSP heritage). I don't really understand why they would ever not be turned on. They also shouldn't ever be removed from the spec.

I understand that they can be turned off, and if I get some time, I'll change the example content and the htmlform views.[/quote]

Its all good I was able to make it work. Its just for the cases where a host is strict and does not allow these sorts of things...

In my case it is a state environment so things getting turned on take about 500 sheets of paper and 100's of hours of work to get a simple thing from off to on...

[eluser]PoetaWD[/eluser]
Another security hole I found:

When editing something, the ID of the object in question was being passed by URL like:

Code:

http://localhost/ejuri/index.php/cprofiles/edit/4

BUT, what if a person from another company type in the url with a object that does not belong to it ? They would be able to see it...

So I ask: is there a is_related function in DMZ ?

So I would be able to do this:

Code:

$obj = new Profile
$obj->get_by_id($this->uri->segment(3))

if($obj->is_related('company','id', '5')
{
....
....
}
else
{
    echo "you dont have permission to edit this";
}

I have made something similar to this:

Code:

if ($this->dx_auth->is_logged_in())
{
if($this->dx_auth->check_poss($this->uri->segment(3),'pfisica',$this->dx_auth->get_company_id()))
{
    $obj = new Pfisica();
    $obj->where_related('company', 'id', $this->dx_auth->get_company_id());
    $obj->get();
}
else
{
    echo  "you do not have the permission"
}
}

And here is the function to check the possesion:

Code:

//Check if the user has access to object
    function check_poss($uri, $object, $id)
    {
        $obj = new $object;
        $obj->get_by_id($uri);
        
        if($id == $obj->company_id)
        {
            return TRUE;    
        }
        else
        {
            return FALSE;    
        }        
    }

The code I wrote does work, but I dont know if it is a better way of doing that using DMZ.

[eluser]OverZealous[/eluser]
@Poetawd

You basically have it. I use very similar code for verification (the where_related). I verify every single object and every value that is passed back to my apps. My apps, however, are often used by "anyone and their brother", so I have to assume that they are trying to break it.

I'm glad you are catching on. It seems like many web developers do not understand basic security, and HTML-based forms are probably the least secure input method of all. I have found a lot of websites with the exact issue you describe.

In the end, the basic, paranoia rule is:

Never trust anything your user sends you.

This is also why it is so critical to apply htmlspecialchars() to every dynamic string value you output to the browser, especially if a user could have edited it.

(And if you want to accept HTML-formatted text — I don't recommend this unless you can pass it through htmltidy — you have to be even more careful, such as using CI's xss filters, possibly limiting which tags are allowed, and more.)

[eluser]PoetaWD[/eluser]
Thanks to you ! You are a AWESOME teacher !

Now I will pay more attention to every single input !

The is_related() function really doesnt exist... I think that would be a good add to DMZ...

A function that would return TRUE if the object is related to another or FALSE if it is not.

Like:

Code:

$cc = new Company;
$cc->get_by_id('ID');

$obj = new Object;
$obj->get_by_id('ID');

if($cc->is_related($obj))
{
    ....
}

or

Code:

$cc = new Company;
$cc->get_by_id('ID');

if($cc->is_related($obj, 'ID'))
{
    ....
}

[eluser]emorling[/eluser]
-- solved my own problem --

[eluser]BrianDHall[/eluser]
I have a suggestion/request that I think is relatively simple.

I had a bug I spent about 10 hours on and could not figure it out, and it turned out that it was this:

I had a model for Listing and Garagetype. In Listing it stated it has a has_one relation to 'garagetype', and in Garagetype I stated it has a has_many relationship to 'listings'.

It worked to save the relationship, but when I wanted to see what the related garagetype was for a given listing it just returned a garagetype with all null data fields. I wracked my brain and couldn't figure out was wrong, even with E_ALL and profiling turned on.

But you know what it was? I said it had a relationship to 'listings'....instead of 'listing'. This made it break, but with no error or notice or clear sign of what went wrong.

Could there be some way to let you know you did something wrong, like referenced a model that didn't exist, etc, to help make it clearer where to look when something breaks?

Whether it be an internal error/warning object or an outright thrown error, a judicious application of this would be really helpful to aide in hunting down those minor little errors that produce such big headaches.


...now, with that said, I did also want to take a moment to thank you for this great offering. It was my first attempt at ORM and, beyond the necessary learning curve and this little bug, I am really impressed.

My first commercial project (with CI, that is) used ActiveRecord, which was so much better than writing SQL by hand I thought CI was just great. Using DataMapper is at least a big an improvement, and perhaps much bigger. I intentionally kept my database suboptimally simple in the past because I wanted to avoid joins and sub-queries and nested references because they were just so hard, but now with DMZ I feel I can design the systems the way the information dictates they should be - and do so with the assurance that it won't cause a ton of work for me at a coding level.

And may I say, I think moving form validation into the models is just an awesome way to handle things. It has simplified my form creation tremendously, and its just a really great step-forward.

Thanks for all your work, it really puts to rest any concern I had that made me look at other frameworks.

-Brian

[eluser]OverZealous[/eluser]
@BrianDHall

Thanks for the positive feedback.

There really isn't a way to detect these kinds of mistakes. The reason is that the relationships and the fields they populate are generated dynamically using PHP magic methods (__get and __call).

I can solve it with methods dynamically created using __call, because a method either exists or it doesn't. It cannot come into existence at a later time, so DMZ throws an error if a method isn't found.

A property can be created or requested at anytime, however. For example, the fields for a DMZ class can either not exist or be null. If I threw an error when an missing property was accessed, it would break a lot of things.

It's a limitation that can prove frustrating, but I have been replacing silently ignored mistakes with errors as I find them. Stensi (the original developer) appears to favor silently discarding mistakes, I prefer loud obnoxious errors whenever possible. ;-)

[eluser]12vunion[/eluser]
Quick question, if I get multiple objects is it possible to grab one of them by index?

example:

Code:

$posts = new Post();
$posts->get_last_5();
//what I'd like to do
$post = $posts[2];

I know the first one can be accessed just from $posts, or I can get them all $posts->all, but can I access an individual one? Or do I have to run another get()?

[eluser]OverZealous[/eluser]
@12vunion
posts->all is an array, you can loop through that. There is no reason to re-get the data.

There is a caveat. The current version of DMZ is based on DataMapper, and DataMapper assigned the objects to the array by id. Meaning, your all array might look like this:

Code:

$post->all = array(
    12 => Post(12),
    45 => Post(45),
    8  => Post(8),
    32 => Post(32)
);

So you can't reference it by index. Personally, I don't like that, but I haven't been comfortable changing the code (because it could break existing applications).

However, I've been thinking about this, and I've decided I'm going to make it a configurable option. The new versions of DMZ will default to having all be the current, id-based array. If the configuration option is set to TRUE, DMZ will always use index-based arrays.

Eventually I'll swap the default behavior.

Update:
I implemented the option, which will be released soon. I decided to go with the default behavior being indexed arrays, and the option being the old style array. The ID-indexed arrays can cause problems (in my experience), so I think it is better to be manually enabled.

[eluser]someoneinomaha[/eluser]
I'm really enjoying working with DMZ so far... thanks for the great library.

I do have one question - it may have been asked before, but I didn't see it when searching the archives.

In this example on the site - using the Array extension:

$related = $n->from_array($_POST, array('message', 'date', 'category'));

Is there any protection against SQL injection?

I know before working with CI, I use the $this->input->post('value) which I understand does prevent SQL injection problems.

Thanks for your time.