Design problem : security layers

Discussion in 'Java' started by subtenante, Apr 17, 2007.

  1. subtenante

    subtenante Guest

    Hi,

    I'm fresh in java (started learning in december, by myself because
    already in "enterprise scope"), and i'm having a little trouble.

    I have to make a website, in jsp, and currently working on the
    business model.

    I'd like to reuse the Objects i write for the frontend in the backend,
    namely the ones in the frontend generally have only getters, and the
    ones in the backend also have setters.

    So for the moment what i do is having two packages, namely frontend
    and backend, and the backend Objects all extend from the frontend
    ones.

    Except that the frontend ones depend on each other : for example an
    article will have an author Object in its attributes. But Author in
    frontend has only getters.
    When i do the backend version, it seems that if i directly extend from
    the frontend class Article, the Author object used will be the one
    from the frontend package also.

    The only solution for the moment that i see is to create the Author
    class as default (non public - non private), and write all the getters
    setters for it. In the frontend I also write all the setters for the
    Author in the Article class.

    Then, when i go to the backend, i can extend and add the setters for
    the Author, which are available.

    But i'm not sure of this design. Anybody have suggestions on this kind
    of problem ? A name of pattern to throw me i could dive into ?

    Thanks.
     
    subtenante, Apr 17, 2007
    #1
    1. Advertising

  2. subtenante

    subtenante Guest

    On Tue, 17 Apr 2007 16:53:48 +0800, subtenante
    <> wrote:

    TYPO CORRECTION :

    >The only solution for the moment that i see is to create the Author
    >class as default (non public - non private), and write all the getters
    >setters for it. In the frontend I also write all the *Getters* for the
    >Author in the Article class.
     
    subtenante, Apr 17, 2007
    #2
    1. Advertising

  3. subtenante

    Lew Guest

    subtenante wrote:
    > But i'm not sure of this design. Anybody have suggestions on this kind
    > of problem ? A name of pattern to throw me i could dive into ?


    "Front Controller", a.k.a. "Model-View-Controller" (MVC).

    JSF and Struts implement it.

    You should have only one entity class, not a hierarchy, for each entity type.

    --
    Lew
     
    Lew, Apr 17, 2007
    #3
  4. subtenante

    Wojtek Guest

    subtenante wrote :
    > Hi,
    >
    > So for the moment what i do is having two packages, namely frontend
    > and backend, and the backend Objects all extend from the frontend
    > ones.


    I usually split my packages by use case. So each package holds all the
    classes required for one function. This includes the servlet, business
    rules code and the Data class. The data class consists of only
    attributes and their respective getter/setter pairs.

    The Data class holds all the information which the JSP needs. The
    information is loaded by the SQL class, inspected by the business class
    (including setting flags). The Data object is then placed into the
    HttpRequest.

    The JSP picks out the Data object from the request and displays the
    information held within it. It may also highlight some information
    depending on the flags.

    With each use case in its own package, and minimal interaction between
    packages (except for the framework), I greatly reduce the probability
    that a change in one package will affect another package.

    --
    Wojtek :)
     
    Wojtek, Apr 17, 2007
    #4
  5. subtenante

    Ed Guest

    On 17 Apr, 17:08, Wojtek <> wrote:

    > > So for the moment what i do is having two packages, namely frontend
    > > and backend, and the backend Objects all extend from the frontend
    > > ones.

    >
    > I usually split my packages by use case. So each package holds all the
    > classes required for one function. This includes the servlet, business
    > rules code and the Data class. The data class consists of only
    > attributes and their respective getter/setter pairs.
    >



    >
    > With each use case in its own package, and minimal interaction between
    > packages (except for the framework), I greatly reduce the probability
    > that a change in one package will affect another package.
    >
    > --
    > Wojtek :)


    An interesting approach. I've often wondered how a package-per-feature
    would look; your package-per-use-case looks even more advanced in that
    direction.

    Wojtek, can you tell me how you handle re-use between use cases?

    ..ed

    --

    www.EdmundKirwan.com - Home of The Fractal Class Composition
     
    Ed, Apr 17, 2007
    #5
  6. subtenante

    Ed Guest

    On 17 Apr, 10:53, subtenante <> wrote:
    > Hi,
    >
    > I'm fresh in java (started learning in december, by myself because
    > already in "enterprise scope"), and i'm having a little trouble.
    >
    > I have to make a website, in jsp, and currently working on the
    > business model.
    >
    > I'd like to reuse the Objects i write for the frontend in the backend,
    > namely the ones in the frontend generally have only getters, and the
    > ones in the backend also have setters.
    >
    > So for the moment what i do is having two packages, namely frontend
    > and backend, and the backend Objects all extend from the frontend
    > ones.


    Subtenante, I've read your post a couple of times, and I'm afraid I
    don't understand. So this post is really a request for more
    information.

    Firstly: what do the words, "Frontend," and, "Backend," mean to you?
    I've a feeling that they are well-defined terms in your field, but I'm
    unfamiliar with them. (I don't know JSP, so maybe they're well-known
    JSP terms, in which case you can stop reading here as all my advice
    will be irrelevant.)

    Secondly, I presume the system you're working on is not gigantic:
    there are no fixed rules for the number of classes per package, but 50
    is generally an upper limit. I presume you're not dealing here with
    more than 100 classes in these two packages.

    >
    > Except that the frontend ones depend on each other : for example an
    > article will have an author Object in its attributes. But Author in
    > frontend has only getters.


    An article has an author: what is it that you're designing? A
    reference library of some sort?

    I truly do not understand why a frontend (whatever that is) should
    only have getters and a backend should only have setters.

    > When i do the backend version, it seems that if i directly extend from
    > the frontend class Article, the Author object used will be the one
    > from the frontend package also.


    Re-use is great, of course. You want to maximise your functionality
    per line of code. But I don't understand how inheriting from one
    package to another automatically brings this benefit.

    If one class in backend inherits from a class in frontend, and then
    that backend class is instantiated, there is only one object
    instantiated: there are not two objects created, one in the backend
    and one in the frontend. You can consider the instantiated object as a
    mash of the backend object and the frontend object: but it's just one
    object, not two.

    >
    > The only solution for the moment that i see is to create the Author
    > class as default (non public - non private), and write all the getters
    > setters for it. In the frontend I also write all the setters for the
    > Author in the Article class.


    I don't understand this: perhaps you could supply more information, or
    details of the specific classes?

    But if I were you, and this is just a project to get you used to Java,
    then I'd forget about re-use. Re-use opportunities will present
    themselves unmistakably (you'll be writing the same methods in
    different places) and when they present themselves, deal with them
    then.

    I'd be far, far more interested in designing a solution to the problem
    you're trying to solve as simply as possible, but with the flexibility
    to change it to any ideas for the future that you might have.

    Also, just as classes are encapsulated behaviour, think of packages as
    encapsulated behaviour of a rougher granularity. If you have a
    reference library application (as guessed) then you'll probably have
    the following funtionality:
    - Create a library.
    - Add a work (with author, and perhaps cross-reference to other
    works).
    - Delete a work.
    - Search for a work (or all works by an author, or any other
    attribute).
    - Save library.

    These are all rough-grained behaviours. And though I wouldn't put each
    in its own package (as Wojtek does - and feel free to chose his
    approach), I'd imagine that you'd have the following packages
    (presuming you're using Model-View-Controller, which you're maybe not
    using, but it's a good way to separate the core functionality from the
    way this is presented to the user, and you did say that you're working
    on the, "Business model," which would be the model here):
    com.subtenante.controller - parses commands from user and kicks off
    execution in the model.
    com.subtenante.model - holding package for main functionality.
    com.subtenante.model.library - holds main functionality for the
    library
    com.subtenante.view - holding package for the presentation of your
    library
    com.subtenante.view.gui - GUI specifics for your library (if any).
    com.subtenante.view.console - text specifics for your library.

    Of coures, using JSP limits your view (you almost certainly won't have
    a console view) but it demonstrates how packages should hold related
    behaviours.

    This also reinforces my lack of comprehension of your frontend and
    backend.

    And that com.subtenante.model.library will be further sub-packaged
    depending on the application you're designing. It could be guessed
    further that a major part of your library could be the search you use
    to interrogate the library, and so maybe the library would have a
    further sub-package:
    com.subtenante.model.library.search

    This is especially true if you could consider using a totally
    different search engine in future.

    Also, perhaps the indexing you use is a substantial piece of behaviour
    that could be replaced by a different system of indexiing in future;
    in this case you'd probably also have:
    com.subtenante.model.library.index

    If you could also envisage some sort of authentication whereby only
    certain users could view the works of certain authors (ok, maybe a bit
    Nazi, but you get the point) then you might want to allow you users to
    log-on and base authentication on them, in which case you might have a
    slew of sub-packages, beginning with:
    com.subtenante.model.library.user
    com.subtenante.model.library.security

    And what if you want to charge people for use of your libary? Well,
    then have:
    com.subtenante.model.user.credit
    com.subtenante.model.user.restrict
    com.subtenante.model.user.history

    Again, the credit sub-package will contain all that behaviour that
    checks the user's back-account to ensure that he has enough money to
    view the work he seeks. The history sub-package will hold the
    functionality to show all the works the user has ever viewed.

    These are, of course, just guesses, but the intent is to show that the
    two packages frontend and backend don't really describe what those
    packages do (outside those expert circles that understand those
    terms).

    Another way to look at it is this: if you have a requirement to change
    something in your system in a few months time, will the person
    implementing the change have a good idea where to look just based on
    the package names?

    Using MVC (sort of) as described above, the programmer will know that
    a change to the GUI will not affect the com.subtenante.model sub-
    packages so much.

    Whether a GUI change will impact frontend or backend more, I have no
    idea.

    >
    > Then, when i go to the backend, i can extend and add the setters for
    > the Author, which are available.
    >
    > But i'm not sure of this design. Anybody have suggestions on this kind
    > of problem ? A name of pattern to throw me i could dive into ?
    >
    > Thanks.


    ..ed

    --

    www.EdmundKirwan.com - Home of The Fractal Class Composition
     
    Ed, Apr 17, 2007
    #6
  7. subtenante

    Wojtek Guest

    Ed wrote :
    > On 17 Apr, 17:08, Wojtek <> wrote:
    >
    >>> So for the moment what i do is having two packages, namely frontend
    >>> and backend, and the backend Objects all extend from the frontend
    >>> ones.

    >>
    >> I usually split my packages by use case. So each package holds all the
    >> classes required for one function. This includes the servlet, business
    >> rules code and the Data class. The data class consists of only
    >> attributes and their respective getter/setter pairs.
    >>

    >
    >
    >>
    >> With each use case in its own package, and minimal interaction between
    >> packages (except for the framework), I greatly reduce the probability
    >> that a change in one package will affect another package.
    >>

    > An interesting approach. I've often wondered how a package-per-feature
    > would look; your package-per-use-case looks even more advanced in that
    > direction.
    >
    > Wojtek, can you tell me how you handle re-use between use cases?


    package names:

    person
    person.common
    person.edit
    person.filter
    person.list

    So the common package holds classes which are used by filter, list,
    and/or edit, yet all are contained within person. These are usually
    data holders.

    In the case where a class might be used all over the place, that whole
    "concept" gets its own package, usually in the framework.

    Where the same code might be used between similar concepts such as
    person.list and apes.list I used redundant code.

    I spent quite a bit of time working out patterns which my use cases
    use, so the same code flow is used in both person.list and apes.list,
    with only imports and variable names being different.

    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.

    Also, I use the minimal posssible scope for everything. So the
    classes/methods in a use case usually have package level scope, that is
    there is no public modifier.

    --
    Wojtek :)
     
    Wojtek, Apr 18, 2007
    #7
  8. subtenante

    subtenante Guest

    Wow, thanks a lot Ed, for the time you spent answering.

    I'll give you a bit more information here.

    On 17 Apr 2007 15:37:08 -0700, Ed <> wrote:
    >Firstly: what do the words, "Frontend," and, "Backend," mean to you?


    The usual in the website paradigm : frontend is the website viewed by
    users, backend the one seen by administrators.

    My concern is security. I perhaps should have said that before.
    I need the normal users of the website to have limited rights on the
    objects they use (most of them don't even know they are creating
    objects on my server, but you see my meaning).
    That's the reason for the frontend package. The objects in that one
    have very limited rights : only getters (and not all of them). This
    way i am sure that the frontend webpages, which only import the
    frontend package, have limited rights.

    On the other end, i need the administrators to work on the objects in
    the database, so create and update them. Therefore i need setters, and
    a DB interface. I wondered if i would have two different classes for
    each object or not, in the beginning i decided to extend the backend
    ones from the frontend ones. But i'm reconsidering this.

    >Secondly, I presume the system you're working on is not gigantic:
    >there are no fixed rules for the number of classes per package, but 50
    >is generally an upper limit. I presume you're not dealing here with
    >more than 100 classes in these two packages.


    Right.

    >An article has an author: what is it that you're designing? A
    >reference library of some sort?


    It's only an example. Although i also have this articles/authors
    structure in my model, it's not the main part.

    >I truly do not understand why a frontend (whatever that is) should
    >only have getters and a backend should only have setters.


    Backend needs both, that why i extend in backend from frontend.

    It's not likely that i am to maintain this project a long time, that's
    why i wanted to be kind to the maintainers and have the least
    redundant code possible.

    >If one class in backend inherits from a class in frontend, and then
    >that backend class is instantiated, there is only one object
    >instantiated: there are not two objects created, one in the backend
    >and one in the frontend. You can consider the instantiated object as a
    >mash of the backend object and the frontend object: but it's just one
    >object, not two.


    I know. Backend users have their own objects, frontend users will
    create theirs by themselves when they connect to the frontend of the
    website.

    >But if I were you, and this is just a project to get you used to Java,
    >then I'd forget about re-use. Re-use opportunities will present
    >themselves unmistakably (you'll be writing the same methods in
    >different places) and when they present themselves, deal with them
    >then.


    Well that's the point. What i don't like about java is the "only one
    inheritance", my problem would be solved otherwise.

    If i do not inherit from the backend to their frontend version, i have
    to recode all the constructors (sometimes heavy ones), and every
    change in one attribute has to be done twice. I'm personnally not much
    worried about it but i might not be the maintainer (and i work in an
    "emerging" country : they have good programmers but poor english and
    therefore limited access to documentation).

    And because there is not multiple inheritance, i have to embed some
    objects in my frontend ones. An author is an attribute of an article.
    But they both are the frontend version (light getters). When i inherit
    in the backend Article, i still have a frontend Author in it. But i
    don't want it : i want a backend Author !

    I was thinking that maybe generics would do the trick, but i'm not
    sure how to make it work right now, and it makes every definition of
    my objects a lot heavier (call
    Article<backend.Author,backend.Language,backend.Comments,...>).
    I guess i could make another screening class that would create these
    objects directly. Have to think about this.

    >These are all rough-grained behaviours. And though I wouldn't put each
    >in its own package (as Wojtek does - and feel free to chose his
    >approach), I'd imagine that you'd have the following packages
    >(presuming you're using Model-View-Controller, which you're maybe not
    >using, but it's a good way to separate the core functionality from the
    >way this is presented to the user


    I thought that my db/jsp/java was already a MVC approach... You're
    telling me there can be different MVC at different scales, that is one
    db/jsp/java and one more within the java code ?

    Anyways, thanks again for you long answer and all the details.
    sub.
     
    subtenante, Apr 18, 2007
    #8
  9. subtenante

    subtenante Guest

    On Tue, 17 Apr 2007 08:08:19 -0400, Lew <>
    wrote:

    >subtenante wrote:
    >> But i'm not sure of this design. Anybody have suggestions on this kind
    >> of problem ? A name of pattern to throw me i could dive into ?

    >
    >"Front Controller", a.k.a. "Model-View-Controller" (MVC).
    >
    >JSF and Struts implement it.
    >
    >You should have only one entity class, not a hierarchy, for each entity type.


    Thanks Lew.

    I have short time, and learning JSF or Struts would have taken too
    much time (i seriously considered them and made a first attempt to use
    them, but the "return on time investment" would not have been good
    enough...).
     
    subtenante, Apr 18, 2007
    #9
  10. subtenante

    subtenante Guest

    On Tue, 17 Apr 2007 15:08:24 GMT, Wojtek <> wrote:

    >subtenante wrote :
    >> Hi,
    >>
    >> So for the moment what i do is having two packages, namely frontend
    >> and backend, and the backend Objects all extend from the frontend
    >> ones.

    >
    >I usually split my packages by use case. So each package holds all the
    >classes required for one function. This includes the servlet, business
    >rules code and the Data class. The data class consists of only
    >attributes and their respective getter/setter pairs.


    Yep, i see your point, and it's mine too !
    I'm not that much splitting the packages,but the backend/frontend
    separation has the same philosophy i think. (In case i need only to
    watch the website, there is the frontend package, in case i need also
    to change the data i have the backend one. But in both cases the
    objects have a lot of similarities.)

    >The Data class holds all the information which the JSP needs. The
    >information is loaded by the SQL class, inspected by the business class
    >(including setting flags). The Data object is then placed into the
    >HttpRequest.


    The thing is that i look at my website as two separate ones. The
    backend interferes with the database, updating it. The frontend only
    reads it. They use the same kinds of objects, but never interact
    directly, they always interact through the DB.

    >With each use case in its own package, and minimal interaction between
    >packages (except for the framework), I greatly reduce the probability
    >that a change in one package will affect another package.


    Well i *want* (and need) that a change in a frontend object makes a
    change on the backend one. I want them both to have almost the same
    attributes, generally, and i want for example all the getters (or
    displaying methods) to be the same in the backend than in the frontend
    (and not to have to do the changes twice every time). But i really do
    not want the frontend objects to be able to make any change in the
    database.
     
    subtenante, Apr 18, 2007
    #10
  11. subtenante

    Wojtek Guest

    subtenante wrote :
    > On Tue, 17 Apr 2007 15:08:24 GMT, Wojtek <> wrote:
    >
    >> The Data class holds all the information which the JSP needs. The
    >> information is loaded by the SQL class, inspected by the business class
    >> (including setting flags). The Data object is then placed into the
    >> HttpRequest.

    >
    > The thing is that i look at my website as two separate ones. The
    > backend interferes with the database, updating it. The frontend only
    > reads it. They use the same kinds of objects, but never interact
    > directly, they always interact through the DB.


    Your JSP pages access the database? Or even know about it?

    In my scenario, the front end only gets information from a Data object.
    So the JSP only knows about the Data object. How that information got
    put into the Data object it totally irrelevant to the JSP.

    The way I have layered the classes, I can switch database technologies
    by simply re-writing ONE set of classes in the "backend", and setting a
    configuration file. Whether that new database is a different database,
    an XML file, a flat file, or whatever, it is completely hidden from the
    JSP.

    A given database class knows how to access its database, the proper
    syntax for that database (including any quirks), and has all the
    methods for the normal CRUDL.

    >> With each use case in its own package, and minimal interaction between
    >> packages (except for the framework), I greatly reduce the probability
    >> that a change in one package will affect another package.

    >
    > Well i *want* (and need) that a change in a frontend object makes a
    > change on the backend one. I want them both to have almost the same
    > attributes, generally, and i want for example all the getters (or
    > displaying methods) to be the same in the backend than in the frontend
    > (and not to have to do the changes twice every time).


    The normal round trip is that the user fills in some information, then
    clicks on a submit button.

    A servlet starts up. It reaches into the request and picks out the page
    fields. Depending on the button, the servlet performs some sort of
    action.

    In my setup, the servlet populates the Data object with the user's
    entered information. If the action is "Update", then the Data object is
    validated. If the validation succeeds, then the Data abject is passed
    to the database class, and the servlet re-directs to another servlet.

    If the validation fails, then the Data object is placed into the
    request, and the JSP is called. The JSP displays the information in the
    Data object (which in this case is the bad information). The JSP also
    displays any error messages.

    If this is the first time to that servlet, then it calls the database
    class to get the information from the database. The database method
    creates the Data object, fills it with values from the database, and
    passes it back to the servlet, which calls the JSP.

    So the JSP only needs to know about ONE object, the Data object.

    > But i really do
    > not want the frontend objects to be able to make any change in the
    > database.


    With only ONE Data object which is passed around, then you only need to
    change that one class. Since it has both getters and setters for a
    given attribute, then any change (almost) automatically is seen by both
    users of the object.

    In your case, any new attribute must be put into two objects.

    Also, since I am using minimal scope, the JSP cannot even get at the
    classes which "play" with the database.



    --
    Wojtek :)
     
    Wojtek, Apr 18, 2007
    #11
  12. subtenante

    subtenante Guest

    On Wed, 18 Apr 2007 13:29:22 GMT, Wojtek <> wrote:

    >Your JSP pages access the database? Or even know about it?


    Well no, i thought it was obvious. The database interface is done in a
    separate package.

    >In my scenario, the front end only gets information from a Data object.
    >So the JSP only knows about the Data object. How that information got
    >put into the Data object it totally irrelevant to the JSP.


    That's my point. I want the jsp from the frontend to use the frontend
    package, containing only lightweight versions of the objects. This
    way, i am sure it is impossible to update anything not permitted from
    the jsp. Only a very few setters are available, and not even all of
    the getters.

    But in the backend of the website, i need the jsp's to use the backend
    package, containing the objects, inheriting from the frontend ones,
    and having the additional features to make changes to the DB.

    This way i am sure that when a new feature is added to a jsp page, it
    can not be problematic for security : from the design level it is not
    permitted to add features to update not permitted information.

    By the way, the frontend package uses a very limited DB account, only
    granted with "execute". For the backend I have a lot of DB accounts,
    each with the necessary rights and no more.

    (Now you are going to think i am paranoid.)
    (Ok, spit it, i don't care.)
    (You know, paranoids also have enemies.)
    (Are you one of them ? Hmm ?)

    >The way I have layered the classes, I can switch database technologies
    >by simply re-writing ONE set of classes in the "backend", and setting a
    >configuration file. Whether that new database is a different database,
    >an XML file, a flat file, or whatever, it is completely hidden from the
    >JSP.


    Easily said, but i guess you would have to browse all your classes to
    make the appropriate changes in the request they do to the DB anyways.
    I think it doesn't minimize the number of lines to change, only the
    place where you store them.
    Am i wrong ?

    >The normal round trip is that the user fills in some information, then
    >clicks on a submit button.
    > ...
    >So the JSP only needs to know about ONE object, the Data object.


    Yes but i have two sets of jsp's. One in the frontend, that must use
    limited versions of the Objects (therefore i give no way to put a mess
    in my data this way, everything is strictly controlled). One in the
    backend, where i am slightly more relax (slightly).

    >With only ONE Data object which is passed around, then you only need to
    >change that one class. Since it has both getters and setters for a
    >given attribute, then any change (almost) automatically is seen by both
    >users of the object.


    Yes but i don't trust the next developpers/maintainers. I have seen
    ugly things, precisely that's the reason i am doing everything from
    scratch. I want a design that makes completely sure that the people
    that will care about this later will understand which data is
    sensitive and which is not, so that they don't do ugly things.

    >In your case, any new attribute must be put into two objects.


    Not if i inherit. Which i'm trying to do, and it seems it's not that
    bad.

    Let's take

    class Article1{
    protected Author1 author;
    ....
    }

    and

    class Article2 extends Article1{
    protected Author2 author;
    ....
    }

    Provided that i have defined Author1 and Author2 each in its
    appropriate package (namely frontend and backend), and Author2 also
    extends from Author1.

    It seems that in Article2, i no longer have any reference to the
    Author1 from the Article1, it is completely replaced by a Author2. So
    i'll try to see but the methods from Article1 are still available, and
    might work on Author2 as if it were a Author1. Which is fine, because
    for the sensible operations, i define everything in Article2.

    Don't know if you get my meaning.
    I think i get it, so i may be able to explain better.

    >Also, since I am using minimal scope, the JSP cannot even get at the
    >classes which "play" with the database.


    But let's say you have two classes : Article and Author.
    You want 6 methods : select, insert and update for each of these
    classes.
    As far as i understand you have one big package database which makes
    the closest part to the database available (pooling connections,
    etc.). You also have two packages :
    article.db
    author.db
    in which you have classes where methods can be found to make the
    operations.
    But how is it inside these packages ? One class per operation ?
    Select.java
    Insert.java
    Update.java
    or one big class for everything ?

    Anyways, thanks for your time.
     
    subtenante, Apr 18, 2007
    #12
  13. subtenante

    Wojtek Guest

    subtenante wrote :
    > On Wed, 18 Apr 2007 13:29:22 GMT, Wojtek <> wrote:
    >
    >> Your JSP pages access the database? Or even know about it?

    >
    > Well no, i thought it was obvious. The database interface is done in a
    > separate package.


    Yes. But does your JSP use database aware classes? That is what i
    meant.

    >> In my scenario, the front end only gets information from a Data object.
    >> So the JSP only knows about the Data object. How that information got
    >> put into the Data object it totally irrelevant to the JSP.

    >
    > That's my point. I want the jsp from the frontend to use the frontend
    > package, containing only lightweight versions of the objects. This
    > way, i am sure it is impossible to update anything not permitted from
    > the jsp. Only a very few setters are available, and not even all of
    > the getters.


    So what you need to do is make your database access classes final, and
    limit their scope to the package. So rather than having:

    -------------------
    public final class Foo()
    {
    }
    -------------------

    You have

    -------------------
    final class Foo()
    {
    }
    -------------------

    That way Foo cannot be extended, and it is not visible outside the
    package.

    > (Now you are going to think i am paranoid.)
    > (Ok, spit it, i don't care.)
    > (You know, paranoids also have enemies.)
    > (Are you one of them ? Hmm ?)


    Yes, I am one of them :)

    --
    Wojtek :)
     
    Wojtek, Apr 18, 2007
    #13
  14. subtenante

    Lew Guest

    Wojtek wrote:
    >> Your JSP pages access the database? Or even know about it?


    subtenante wrote:
    > Well no, i thought it was obvious. The database interface is done in a
    > separate package.


    So your JSPs do not use the database classes.

    (BTW, JSPs aren't usually thought of as being in a package.)

    > That's my point. I want the jsp from the frontend to use the frontend
    > package, containing only lightweight versions of the objects. This
    > way, i am sure it is impossible to update anything not permitted from
    > the jsp. Only a very few setters are available, and not even all of
    > the getters.


    You enforce security by how you access an object, not by needless duplication
    of the object.

    > But in the backend of the website, i need the jsp's to use the backend
    > package, containing the objects, inheriting from the frontend ones,
    > and having the additional features to make changes to the DB.


    JSPs are a strictly front-end artifact. JSPs "in the backend [sic]" are a
    contradiction in terms. JSPs are for visual presentation (or the equivalent),
    the very definition of "front end".

    > This way i am sure that when a new feature is added to a jsp page, it
    > can not be problematic for security : from the design level it is not
    > permitted to add features to update not permitted information.


    This is better done without duplicating your classes.

    > By the way, the frontend package uses a very limited DB account, only
    > granted with "execute". For the backend I have a lot of DB accounts,
    > each with the necessary rights and no more.


    You really only need one DB account for the whole DB layer, and the front end
    would never access it.


    >> The way I have layered the classes, I can switch database technologies
    >> by simply re-writing ONE set of classes in the "backend", and setting a
    >> configuration file. Whether that new database is a different database,
    >> an XML file, a flat file, or whatever, it is completely hidden from the
    >> JSP.


    > Easily said, but i guess you would have to browse all your classes to
    > make the appropriate changes in the request they do to the DB anyways.
    > I think it doesn't minimize the number of lines to change, only the
    > place where you store them.
    > Am i wrong ?


    Yes, you are.

    The truth is exactly the opposite. You don't "browse all your classes to make
    the appropriate changes", you open the source for the one and only one class
    that needs a change. The number of lines to change is approximately half of
    the scheme that you propose.

    > Yes but i have two sets of jsp's. One in the frontend, that must use
    > limited versions of the Objects (therefore i give no way to put a mess
    > in my data this way, everything is strictly controlled). One in the
    > backend, where i am slightly more relax (slightly).


    JSPs are front-end artifacts. Only.

    What do you mean by a "set of jsp's [sic] ... in the backend [sic]"?

    The phrase makes no sense to me whatsoever. Why would you want HTML in the
    back end, where no one can see it?

    > Yes but i don't trust the next developpers/maintainers. I have seen
    > ugly things, precisely that's the reason i am doing everything from
    > scratch. I want a design that makes completely sure that the people
    > that will care about this later will understand which data is
    > sensitive and which is not, so that they don't do ugly things.


    This can be accomplished without making maintainers' jobs more difficult, too.

    I strongly recommend that you study Wojtek's suggestions in depth. They are
    sound and will accomplish the goals of isolation and security that you
    espouse, with a sturdier and more compact architecture.

    --
    Lew
     
    Lew, Apr 19, 2007
    #14
  15. subtenante

    subtenante Guest

    Thanks for your answers Lew. No need though to talk to me as if i were
    stupid (maybe i am, but that's not quite polite, and not the best way
    to make me understand my mistakes). If you don't understand my
    questions, it's because we don't talk about the same thing. When i say
    backend, i mean backend of a website. The place where administrators
    connect via a http/html interface to update the information of the
    website. Everybody i know working on websites calls this a backend
    (implicitly : of the website).

    My security concern is not only about the users, it's also about the
    maintainers. Who often do nonsensical things here. I have special
    requirements. And i'm being listening to the answers of Wojtek, and
    asking him questions. Now if my language seems strange to you, maybe
    it's also because i'm not a native english speaker, and i'm doing my
    best.

    On Wed, 18 Apr 2007 19:53:24 -0400, Lew <>
    wrote:

    >JSPs are a strictly front-end artifact. JSPs "in the backend [sic]" are a
    >contradiction in terms. JSPs are for visual presentation (or the equivalent),
    >the very definition of "front end".
     
    subtenante, Apr 19, 2007
    #15
  16. subtenante

    subtenante Guest

    On Wed, 18 Apr 2007 18:23:18 GMT, Wojtek <> wrote:
    >Yes. But does your JSP use database aware classes? That is what i
    >meant.


    They did. They won't.

    >That way Foo cannot be extended, and it is not visible outside the
    >package.


    Ok.
    I'm still worried about maintainance but i guess you've got nothing
    for free.

    >> (Now you are going to think i am paranoid.)
    >> (Ok, spit it, i don't care.)
    >> (You know, paranoids also have enemies.)
    >> (Are you one of them ? Hmm ?)

    >
    >Yes, I am one of them :)


    Whether you are or not (they all are anyways !) you seriously helped
    me.
    I'm not sure i'll do things right this way from the beginning but i
    guess i'll learn by doing it.
    Thanks for your time.
     
    subtenante, Apr 19, 2007
    #16
  17. subtenante

    subtenante Guest

    On Wed, 18 Apr 2007 19:53:24 -0400, Lew <>
    wrote:

    >You really only need one DB account for the whole DB layer, and the front end
    >would never access it.


    Reading your post again i could not really understand why you say
    this. I have a "pool of pools" for my DB connections, i can't see why
    i should have one account with all rights on all the tables, when i
    can have several pools of accounts each of them dealing with its own
    part of the db.

    >> Easily said, but i guess you would have to browse all your classes to
    >> make the appropriate changes in the request they do to the DB anyways.
    >> I think it doesn't minimize the number of lines to change, only the
    >> place where you store them.
    >> Am i wrong ?

    >
    >The truth is exactly the opposite. You don't "browse all your classes to make
    >the appropriate changes", you open the source for the one and only one class
    >that needs a change. The number of lines to change is approximately half of
    >the scheme that you propose.


    I don't get it. Suppose you want to switch from a regular database to
    an xml file, as Wojtek gave as example. You will still have to make
    the changes for each type of operation for each type of object you
    have. All these methods exist in any scheme, and would have to be
    changed all the same, whichever class they are stored in.

    I have two classes : Article and Author.
    You mean that all the functions to add, retrieve, update and delete
    lines in my db must be in the very same class, say DBInterface, and i
    should do for example :
    DBInterface.retrieveArticle(...),
    DBInterface.addArticle(...), etc., and
    DBInterface.retrieveAuthor(...),
    DBInterface.addAuthor(...), etc. ?

    I thought Wojtek meant i should have a package article.dbinterface in
    which i would find the classes to do the changes.

    Anyways i don't see why it makes half the lines to change. I still
    think that's the same number of lines but all of them put in one
    class, or split in packages depending on each concept.

    >> Yes but i don't trust the next developpers/maintainers. I have seen
    >> ugly things, precisely that's the reason i am doing everything from
    >> scratch. I want a design that makes completely sure that the people
    >> that will care about this later will understand which data is
    >> sensitive and which is not, so that they don't do ugly things.

    >
    >This can be accomplished without making maintainers' jobs more difficult, too.


    Well, Wojtek himself admitted that his method was a lot of
    maintaining, with a lot of duplicated code for similar objects. Could
    you tell me how to avoid it ?

    >I strongly recommend that you study Wojtek's suggestions in depth. They are
    >sound and will accomplish the goals of isolation and security that you
    >espouse, with a sturdier and more compact architecture.


    Inch'allah.
     
    subtenante, Apr 19, 2007
    #17
  18. subtenante

    Lew Guest

    subtenante wrote:
    > Thanks for your answers Lew. No need though to talk to me as if i were
    > stupid (maybe i am, but that's not quite polite, and not the best way
    > to make me understand my mistakes). If you don't understand my
    > questions, it's because we don't talk about the same thing. When i say
    > backend, i mean backend of a website. The place where administrators
    > connect via a http/html interface to update the information of the
    > website. Everybody i know working on websites calls this a backend
    > (implicitly : of the website).


    No one is calling you stupid or even implying it. No one said anything about
    your use of language, either. These matters are irrelevant to the discussion.

    Use of terms, as opposed to use of language, is another matter. Definitions
    of terms matter.

    "Back end" is a more-or-less standard term, albeit imprecise, and means
    roughly the data storage and related layers of an app. "Front end" is a
    more-or-less standard term and loosely means the user interface layer. In the
    common understanding of these terms, having a JSP in the "back end" is a
    contradiction in terms.

    If you use these terms in a different way you should explain how your use
    differs from the common usage, otherwise you cannot blame someone for
    misunderstanding you.

    --
    Lew
     
    Lew, Apr 19, 2007
    #18
  19. subtenante

    subtenante Guest

    On Thu, 19 Apr 2007 08:31:38 -0400, Lew <>
    wrote:

    >Use of terms, as opposed to use of language, is another matter. Definitions
    >of terms matter.


    Alright, sorry. To me, 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.
     
    subtenante, Apr 19, 2007
    #19
  20. subtenante

    Lew Guest

    Lew wrote:
    >> You really only need one DB account for the whole DB layer, and the front end
    >> would never access it.


    subtenante wrote:
    > Reading your post again i could not really understand why you say
    > this. I have a "pool of pools" for my DB connections, i can't see why
    > i should have one account with all rights on all the tables, when i
    > can have several pools of accounts each of them dealing with its own
    > part of the db.


    I say it because it's true. It's possible to develop an app that uses one DB
    account, e.g., "myapp" for application "MyApp".

    As to why you should or shouldn't do that, 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.

    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.

    >>> Easily said, but i guess you would have to browse all your classes to
    >>> make the appropriate changes in the request they do to the DB anyways.
    >>> I think it doesn't minimize the number of lines to change, only the
    >>> place where you store them.
    >>> Am i wrong ?

    >> The truth is exactly the opposite. You don't "browse all your classes to make
    >> the appropriate changes", you open the source for the one and only one class
    >> that needs a change. The number of lines to change is approximately half of
    >> the scheme that you propose.

    >
    > I don't get it. Suppose you want to switch from a regular database to
    > an xml file, as Wojtek gave as example. You will still have to make
    > the changes for each type of operation for each type of object you
    > have. All these methods exist in any scheme, and would have to be
    > changed all the same, whichever class they are stored in.


    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.

    > Anyways i don't see why it makes half the lines to change. I still
    > think that's the same number of lines but all of them put in one
    > class, or split in packages depending on each concept.


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

    Furthermore the lines will be together, not spread across multiple artifacts.
    Less maintenance work, lower TCO.

    > Well, Wojtek himself admitted that his method was a lot of
    > maintaining, with a lot of duplicated code for similar objects. Could
    > you tell me how to avoid it ?


    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.

    >> sound and will accomplish the goals of isolation and security that you
    >> espouse, with a sturdier and more compact architecture.


    > Inch'allah.


    God helps those who help themselves.

    --
    Lew
     
    Lew, Apr 19, 2007
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Jan Brunia
    Replies:
    1
    Views:
    562
    Pronab Pal
    Feb 10, 2004
  2. murmur
    Replies:
    1
    Views:
    454
    Jerry Perkins
    Oct 27, 2003
  3. HoDeHoo

    Layers Problem

    HoDeHoo, Feb 27, 2006, in forum: HTML
    Replies:
    0
    Views:
    442
    HoDeHoo
    Feb 27, 2006
  4. HoDeHoo

    PHP/Layers Problem

    HoDeHoo, Feb 27, 2006, in forum: HTML
    Replies:
    6
    Views:
    533
    Neredbojias
    Feb 28, 2006
  5. Rob Meade

    Question regarding oo design / layers

    Rob Meade, Jun 21, 2007, in forum: ASP .Net
    Replies:
    2
    Views:
    350
    Rob Meade
    Jun 22, 2007
Loading...

Share This Page