Posted by Kenneth Downs on 05/01/07 15:23

Henk verhoeven wrote:

> Kenneth Downs wrote:
>> (..) the trouble doesn't start until you put in the filters. At
>> this point we punted on that and are having using enter SQL expressions
>> like "dob < '1990-01-01'".
> Interesting, i have learned to think of SQL injection as a security
> breach, you seem to be doing it on purpose**
> ** Yes, i read your remark on this subject on
> http://www.andromeda-project.org/pages/cms/SQL+Injections
> It seems to me that you do not expect application developers to extend
> the security beyond what can be arranged on the database.

Henk, thanks for the reply, it is always a pleasure to talk shop with
another framework author.

We probably need lots of discussion on the different assumptions between
Andromeda and phpPeanuts before we can draw conclusions. That being said,
I suspect, based on your remarks, and on prior experience, that your
framework connects to the database as a super-user and your code (or
application code) handles security. Andromeda does not do this. This
reflects not merely a different implementation of similar ideas about
security, but a deeply different ideas about security itself.

Because all security for a database application in the end becomes rules
about who can read or write to what table, Andromeda skips all unnecessary
and obfuscating layers and just specifies in advance who can read or write
to what tables. When the database is built the security is applied to all
tables. Users then connect with their own credentials. The job of the UI
is to conveniently present everything they are allowed to do. Anything
they are not allowed to do they should not see, not because it is insecure,
but because it would be confusing to show them something that they then
could not actually execute.

I do not expect application developers to extend the security because they
cannot. All code executes as the user and so is limited to the user's
security. (In fact, the only exception to this is the ability of the
programmer to elevate security ranking to
admin or some other level, but we needed that for only a single purpose,
which is now satisfied by other means, and we will be removing even that).

<snip>

>
>> Try using fpdf to generate the output, it's well documented and gives
>> nice PDF files, with some smooth stuff for headers, footers, auto page
>> breaks, page numbers and all of that necessary and cumbersome stuff.
>
> Sounds good! PhpPeanuts only outputs HTML. Might be nice to combine the
> both, but Andromeda is licensed under GPL, so it would mean any
> application programmers code that (indirectly) calls upon Andromeda
> components will have to be GPL-ed*, i don't like to force that upon the
> developers that are using phpPeanuts. Luckily there is another pdf
> library that has a BSD-style license (like phpPeanuts), so i rather have
> a litte more work whenever the need arrives for pdf output (i.e. a
> customer wants to pay for it).


Two issues here. First is the GPL. My intention for licensing is that
applications are not considered derivative works, so I am investigating
whether I should switch to LGPL. More on that later.

Second issue is merging/combining. Who knows? Hard to say until we've
looked at each other's code.

>
> Furthermore, phpPeanuts is object-oriented, mapping the object's data to
> database records.

I first got into OO in the 90s, developed OO mania late 90s/early 2000s, and
can now say, "been there, done that, not interested". The inescapable trap
of OO framework development is assuming that code is a lasting asset, and
that if it could only be structured right, it would have lasting value, it
would at long last be "reusable." But it just ain't so. Code expires.
Data survives.

Now, once a person has seen the design cycle 2 or 3 times and realized that
the entire framework is doomed, he looks for something that will survive
the sea changes. This puts a person in the frame of mind to examine the
first fact of Andromeda: "All business rules resolve to database
specifications." From here we realize that what lasts is a description of
the business rules, which is nothing more than a description of the
database. (IF, and its a big IF, if you can work out what that description
itself must look like). The creative act in writing Andromeda was not the
coding, but describing the description.

This also leads to another huge difference between Andromeda and the others,
we have precious little code in the framework. The builder is about 6000
lines and the entire framework is another 10000, and we work hard to keep
the line count low. Minimize code, maximize data.


As I said before, there are so many differences in our approach that simple
things like "object oriented" require considerable conversation before we
can get at why you went one way and I went another.



> This allows one to add functions written in php to the
> domain model, navigate it, build and maintain hierarchies and have
> polymorphism. OTOH, If you want the freedom to JOIN and GROUP BY, the
> table-oriented aproach of Andromeda will probably suit you better.

None of those features require OO. In fact, nothing *requires* OO.


>
> Greetings,
>
> Henk Verhoeven,
> www.phpPeanuts.org.
>
> * It is my understanding of GPL that any code that links with code that
> is licensed under GPL is a derived work, unless it does not depend ont
> the code under GPL. Applications typically wil depend on the framework,
> so if they are delevered they must be licensed under GPL to third
> parties, which may mean the entire public. With an interpreted language,
> calling methods must be condidered (dynamic) linking. Providing the full
> adromeda source may allow the application developer to withhold his own
> source, but that is kind of hard with PHP unless you only rent hosted
> applications as a service, so no code is delevered.
>


--
Kenneth Downs
www.secdat.com
www.andromeda-project.org

[Back to original message]