Design problem : security layers

[Lew]

... To me,

That's nice.

in the context of a website, i thought it was clear that frontend was what the basic users have access to via their
web browser, and backend what the administrators of the website have
access to, also via their web browser.

In software design, the front-end is the part of a software system that interacts directly with the user, and the back-end comprises the components that process the output from the front-end. The separation of software systems into "front ends" and "back ends" is a kind of abstraction that helps to keep different parts of the system separated.

Like I said, if you use the term in an uncommon way you should explain it. It
is anything but "clear" that your idiolectic definitions applied.

 

[Wojtek]

subtenante wrote :

Well, Wojtek himself admitted that his method was a lot of
maintaining, with a lot of duplicated code for similar objects.

A lot of INITIAL maintaining.

"If I need to make a pattern change (really rare now), then I go
through all the code, so that all the same patterns really are the
same.

Maintaining the pattern IS a lot of work, but once set, it makes
creating new use cases a snap. Create a package set, copy, paste,
rename some classes, rename some variables, and there you go, a working
robust list and edit."

The second paragraph is the reward for the initial work.

I can add a complete Create, Update, Retrieve, Delete, List, Filter for
a new table in less than a day.

That is 5 web pages (Create/ Update are one page) and all the
associated code (typically about 30 classes), with inter-woven user
security, proven code flow (pattern), and a high degree of confidence
that the code WILL work. With the liberal use of constants and scope
limiting the compiler catches almost all of the copy/paste issues.

And the duplicated code is for use case isolation. I can rip out almost
any use case and, except for loss of funcionality, there is no impact
on the rest of the system. All I have to do is remove it from the menu,
and delete the entire package set.

The same applies when adding new use cases.

I will go to great lengths to preserve the robustness of code and its
maintainability. About 25 years of progrmming has taught me it is more
important than trying to achieve ideals.

Ha, I've dated myself...

 

[subtenante]

As to why you should or shouldn't do that, it depends.

Your answers puzzle me, yesterday i really only need one DB account
for the whole DB layer, now it depends ?

I usually use only a
single account because only the application I write uses the DB. Since users
don't need to access the DB, they don't need individual accounts. Fewer
accounts means less maintenance and lower Total Cost of Ownership (TCO) for my
customers, and higher control of security.

I was absolutely not talking about one account per user. I was talking
about one account for all the normal situations and one other per
sensible operation.

Look, i told you i am not trusting the people who are going to
maintain the website later (i'm not even completely trusting myself).
Few people here are aware of SQL injection. Even when they are, they
are not completely sure of how to avoid it, and may let big holes in
the website. So there is no way i put one big account for everything.

The application only deals with "its own part" of the DB. It has
authentication / authorization logic to determine what /its/ users are allowed
to do, but user access to the DB doesn't exist so those types of issues never
arise. Better control, lower TCO.

"User access to the DB doesn't exist" doesn't mean a lot to me. You
only need one unchecked input from a user to have a hole, no matter
how many layers you have between the HTML form and the SQL request.

But they will be in only one class, not two or an inheritance-tree-full. And
classes on the front end will not even see the change, much less be involved
in it. Lower maintenance effort, lower TCO.

So it is an implicit yes to the example i asked if it were right ?

I shouldn't have said "half", I should have said a moiety of lines compared to
duplicating the code in multiple layers.

We may not be talking about the same initial scheme then, because to
me it means only changing one line per method : namely the one with
the SQL request, plus the general DB interface class. I agree that it
helps have then stored in only one file, but even like this, it's not
very hard to find them in all your classes with a little regexp search
in your work directory.

You can't avoid the work, but you can make it easier and pleasanter. Layered
architecture is a proven concept that has shown its value across gazillions of
projects.

You're speaking like a salesman. I have my own requirements, i told
you. It may or may not fit. I don't care of how many projects it
worked for if it doesn't match for mine.

God helps those who help themselves.

Amen.

 

[subtenante]

That's nice.

Please, it was a humble admittance of personal ignorance. And a
tentative to explain why i didn't explain a word i *thought* was
clear, because the only acception of it i knew was the one i used.
Should i explain every word i say in case there is another technical
meaning i am not aware of ?

Like I said, if you use the term in an uncommon way you should explain it. It
is anything but "clear" that your idiolectic definitions applied.

I already got your point, and i apologized. It's not enough ?

We misunderstood each other, i'm very very very sorry.

 

[subtenante]

subtenante wrote :

A lot of INITIAL maintaining.

When does the initial maintaining end then ?

I can add a complete Create, Update, Retrieve, Delete, List, Filter for
a new table in less than a day.

That is 5 web pages (Create/ Update are one page) and all the
associated code (typically about 30 classes), with inter-woven user
security, proven code flow (pattern), and a high degree of confidence
that the code WILL work. With the liberal use of constants and scope
limiting the compiler catches almost all of the copy/paste issues.

The thing is i can't get how you can make 30 classes for these 6 use
cases. I mean, could you give me an example of the classes you find in
these packages ? Do they also follow a certain sub-pattern that comes
back frequently ? For the moment, the way i see it, i would hardly
have one class in each package, which does not make that much sense.

And the duplicated code is for use case isolation. I can rip out almost
any use case and, except for loss of funcionality, there is no impact
on the rest of the system. All I have to do is remove it from the menu,
and delete the entire package set.

Ok, i get it, which makes me think again that the main problem of java
for this pattern is the impossibility to multi-inherit.

What about inheritance for these use cases. Do you use it for
particular things ? Or almost never ?

I will go to great lengths to preserve the robustness of code and its
maintainability. About 25 years of progrmming has taught me it is more
important than trying to achieve ideals.

I'm not even sure what my ideals are...

Ha, I've dated myself...

Better saying it than never having the occasion of !

 

[Wojtek]

subtenante wrote :

The thing is i can't get how you can make 30 classes for these 6 use
cases. I mean, could you give me an example of the classes you find in
these packages ? Do they also follow a certain sub-pattern that comes
back frequently ? For the moment, the way i see it, i would hardly
have one class in each package, which does not make that much sense.

In the folowing, a leading x is the use case name, so where you see
xEdit that could mean PersonEdit.

Editing use case:
xEdit
xEditPage
Command
Data
SQL
SQL_Microsoft
Validator

List use case:
xList
xListAll
xListPage
xListAllPage
xPrintView
xPrintViewPage
Command
Data
Row
SortOrder
SQL
SQL_Microsoft
ViewData

Where a class has a name such as PersonEdit (or xEdit above), that is
the servlet which is called by the application server (Tomcat). The
servlet takes care of all navigation and calling the Command object. By
navigation I mean that if the user clicks on Cancel, then that goes to
another page. If an error occures, then we go to that page, etc.

classes ending in Page hold page specific information such as field
names. The JSP uses these names in the field name parameter (<input
name="<%= PersonPage.USERID %>"> The Command class uses these field
names to extract the information the user entered from the request and
to place it in the Data object.

The list function will paginate the rows, that is 1-20, 21-40, 41-45,
and so on. The list all shows all the rows, and is used for printing
the list.

The SortOrder holds constants for which column is being sorted. A
column on the List page (JSP) has a clickable header cell. That calls
the xList servlet which calls the Command, which calls the SQL which
uses a case statement (using the SoftFilter constants) to generate an
"order by" clause which sorts by that column.

Command contains the business rules.

Validator validates the user input.

ViewData holds detailed information for a single row. This is displayed
below the list, and the user can click on a View button, or PrintView

SQL is an abstract class containing the methods which will be used for
SQL operations. For the Comand class to run SQL operations, it calls
SQL.getInstance(TransactionLevel). The .getInstance determines the type
of database vendor being used, and instantiates that class.

SQL_x is a vendor specific class extending the SQL class, and has the
actual SQL syntax for that vendor. If (for whatever reason) a different
vendor is used, then only this set of classes need to be re-written.
The vendor is specified in the configuration.properties file, along
with connection parameters.

So that is 19 classes.

Of course there are other classes in the framework. For instance the
Validator extends BaseValidator which has a lot of utility functions
such as checkBlank(String value), which will make sure that value is
not empty. If it is empty a message will be created which the user will
see, and isError() will return true. Same for numberRange(long value,
long minValue, long maxValue), dateOrder(Calendar start, Calendar end),
and so on.

I also use a database pool manager (proxool) which opens four
connections intitially, up to a maximum of 20. All SQL operations get a
connection from the pool, so connection overhead is minimal.

 

[subtenante]

In the folowing, a leading x is the use case name, so where you see
xEdit that could mean PersonEdit.
...
I also use a database pool manager (proxool) which opens four
connections intitially, up to a maximum of 20. All SQL operations get a
connection from the pool, so connection overhead is minimal.

Hmm. I do feel stupid now... That's more work than my time can afford
i'm afraid. But that's clear and wil be very useful in the future.

Thanks a lot !