[j2ee] objecten uit de html terug vinden.

[Alarmnummer]

Als je een webpagina maakt, heb je een referentie nodig naar het object op de server om daar de actie op uit te laten voeren.

vb:

<a href="verwijderService?id=1">verwijder persoon</a>

Op deze manier kan de verwijderService het object met id 1 ophalen en deze verwijderen.

Op dit moment gebruiken wij een HandleStringConverter waarbij ieder object een unieke id genereerd en waarbij op basis van dit id het juiste object weer terug gevonden kan worden. Wij krijgen zoiets dus:

<a href="verwijderService?id=Persoon:1">verwijder persoon</a>

Ik vraag me af in hoeverre dit een praktische oplossing is. De handlestring converter neemt contact op met de DAO en zal een query uitvoeren op de db om het object weer terug te krijgen (alhoewel de kans groot is dat je gewoon een object uit de cache terug krijgt).

Welke technieken gebruiken jullie om de communicatie tussen een platte tekst pagina (html) en java te laten verlopen.

[ Voor 9% gewijzigd door Alarmnummer op 05-01-2005 15:42 ]

[-FoX-]

Ik heb me ook altijd al afgevraagd wat nu de juiste methode zou zijn om je html-code met je java-code te laten communiceren.

Eén van die mogelijkheden is, zoals je zelf al aangaf, om aan een bepaalde DeleteUserService een id mee te geven die dan de juiste parameters zal doorgeven naar je facade en uiteindelijk je dao zodat het object verwijderd kan worden.

Op zich werkt dit wel vrij goed, al ben ik niet zo te vinden voor de aanpak om deze gegevensoverdracht via een GET te laten verlopen. Om de bekende reden dat bepaalde domme eindgebruikers wel eens op dit moment het idee zouden kunnen krijgen om de applicatie toch maar te bookmarken En zal er dus, bij iedere bookmark-access, je DeleteUserService aanroepen worden.. met alle gevolgen vandien.

Waarom werk je eigenlijk met een handlestring converter? Is het puur zodat je een generieke Verwijder service kan hebben, die op zijn beurt (adhv de handle), het juiste object kan verwijderen Of hangen er nog meer voordelen verbonden aan deze aanpak, mss even verder toelichten?

Een andere mogelijkheid is om het 'te verwijderen object' in de request te stoppen, en op deze manier het object door te geven aan de DAO.. al is dit misschien een te dure operatie?!

More comments welcome!

[Alarmnummer]

-FoX- schreef op donderdag 06 januari 2005 @ 11:04:

Eén van die mogelijkheden is, zoals je zelf al aangaf, om aan een bepaalde DeleteUserService een id mee te geven die dan de juiste parameters zal doorgeven naar je facade en uiteindelijk je dao zodat het object verwijderd kan worden.

De service krijgt gewoon objecten mee. De controller die peutert uit de request de id.. en vraagt aan de handlestringconverter van die id weer het bijbehorende object. Met dit object roept hij de service aan.

Waarom werk je eigenlijk met een handlestring converter? Is het puur zodat je een generieke Verwijder service kan hebben, die op zijn beurt (adhv de handle), het juiste object kan verwijderen Of hangen er nog meer voordelen verbonden aan deze aanpak, mss even verder toelichten?

De HandleStringConverter (niet mijn naam) heeft 2 functies:

Object FromHandle(string handle);
string getHandle(Object o)

[Janoz]

Ikzelf zou eerder voor meer acties kiezen. niet een VerwijderService action, maar een VerwijderPersoonAction en vervolgens in deze actie implementeren dat je de VerwijderService een persoon met dat id wilt laten verwijderen.

[Alarmnummer]

Janoz schreef op donderdag 06 januari 2005 @ 12:04:
Ikzelf zou eerder voor meer acties kiezen. niet een VerwijderService action, maar een VerwijderPersoonAction en vervolgens in deze actie implementeren dat je de VerwijderService een persoon met dat id wilt laten verwijderen.

Jij werkt dan met een id naar die actie toe. In de html staat dan
<a href="actie2153">verwijder jantje</a>

En op het moment dat die request op de server binnenkomt, zoek je de bijbehorende actie (met id actie2153) er weer bij op? Zodat je die kan uitvoeren.

Wasigh vertelde me gisteren ook al zoiets voor .NET

[ Voor 13% gewijzigd door Alarmnummer op 06-01-2005 12:12 ]

[Janoz]

Ik gebruik struts. Die controler leest een actionmapping xml in waarin acties worden gedefinieerd (naam, bijbehorende class, extra opties, bijbehorende jsps afhankelijk van het resultaat) en formulieren (welke velden meegestuurd kunnen worden en wat de types zijn). Binnen die actie class kan dan vervolgens de buisness logic aangesproken worden.

Urls die je dan krijgt (bij een servlet mapping van *.do) zijn als <a href="/blaat/verwijderpersoon.do?id=1">verwijder petertje</a>

[-FoX-]

Janoz schreef op donderdag 06 januari 2005 @ 12:48:
Ik gebruik struts. Die controler leest een actionmapping xml in waarin acties worden gedefinieerd (naam, bijbehorende class, extra opties, bijbehorende jsps afhankelijk van het resultaat) en formulieren (welke velden meegestuurd kunnen worden en wat de types zijn). Binnen die actie class kan dan vervolgens de buisness logic aangesproken worden.

Urls die je dan krijgt (bij een servlet mapping van *.do) zijn als <a href="/blaat/verwijderpersoon.do?id=1">verwijder petertje</a>

Akkoord, al vind ik dit zelf zeker geen mooie oplossing (zie mijn bookmark verhaal). De gebruiker zou bijvoorbeeld ook willekeurige cijfertjes kunnen ingeven als id, waardoor er een en ander misloopt in het hele systeem. Onder het motto: Never trust user input vind ik dit nogal 'gevaarlijk', zeker bij bvb een verwijder-actie.

[Verwijderd]

-FoX- schreef op donderdag 06 januari 2005 @ 12:55:
[...]

Akkoord, al vind ik dit zelf zeker geen mooie oplossing (zie mijn bookmark verhaal). De gebruiker zou bijvoorbeeld ook willekeurige cijfertjes kunnen ingeven als id, waardoor er een en ander misloopt in het hele systeem. Onder het motto: Never trust user input vind ik dit nogal 'gevaarlijk', zeker bij bvb een verwijder-actie.

delete/modify/create (alles behalve read dus) gebeurt bij ons in transactieschermen. Indien het niet overdreven is gebeurt dat met een POST, maar soms met een GET. In ieder geval krijgt de gebruiker daar geen scherm te zien en wordt hij geforward naar een relevante viewpagina (meestal dezelfde pagina waar de link stond). Op die manier is het niet mogelijk die pagina te bookmarken/refreshen aangezien je ze niet meer terug te zien krijgt. (verder heeft Struts nog het systeem van de tokens).

Als er invoervelden aan te pas komen werken we zelfs in frames en na de save forwarden we naar een success pagina met een simpel regeltje tekst. Daarna escapen we uit die frame naar de relevante viewpagina voor de gewijzigde gegevens.

willekeurige cijfers worden afgevangen door d eobject layer (security). En zowiezo, garbage in, garbage out!! Niemand moet zomaar beginnen klooien met parameters. Ze kunnen net zo goed een eigen HTML formpje aanmaken op hun desktop en posten naar onze applicatie... tja, we zouden er rekening mee kunnen houden, als het budget verdubbelt

[Alarmnummer]

Verwijderd schreef op donderdag 06 januari 2005 @ 15:13:
[...]
willekeurige cijfers worden afgevangen door d eobject layer (security). En zowiezo, garbage in, garbage out!! Niemand moet zomaar beginnen klooien met parameters. Ze kunnen net zo goed een eigen HTML formpje aanmaken op hun desktop en posten naar onze applicatie... tja, we zouden er rekening mee kunnen houden, als het budget verdubbelt

Ik zie eigelijk niet echt security problemen. Alle controlers forwarden de echte logica naar de services en daarbij wordt de security gechecked. Dus iemand mag een lading erop los prutsen met gekke url`s, maar door de service kom je niet ongecontroleerd heen.

Ik gebruik trouwens
Spring icm Acegi Security

[ Voor 10% gewijzigd door Alarmnummer op 06-01-2005 15:40 ]

[Janoz]

-FoX- schreef op donderdag 06 januari 2005 @ 12:55:
[...]

Akkoord, al vind ik dit zelf zeker geen mooie oplossing (zie mijn bookmark verhaal).

Dit is natuurlijk maar een heel klein gedeelte. In de actionmapping wordt bij een verwijder actie gewoon weer een overzichtsactie aangeroepen. Dit gaat via een clientside redirect waardoor die url nooit in de adresbalk te zien is.

De gebruiker zou bijvoorbeeld ook willekeurige cijfertjes kunnen ingeven als id, waardoor er een en ander misloopt in het hele systeem. Onder het motto: Never trust user input vind ik dit nogal 'gevaarlijk', zeker bij bvb een verwijder-actie.

Security is wel degelijk goed geregeld, maar dat zit ergens anders. je wilt niet overal rekening moeten houden met de exacte implementatie van de security omdat dit alleen maar fouten oplevert. Ikzelf gebruik jaas. Elke actie heeft een aantal rollen. Waneer de gebruiker niet aan die rol voldoet dan mag de gebruiker die actie niet uitvoeren. Die rollen kunnen ook afhankelijk van de input zijn.

Daarnaast zorgt het formulier an sich al ervoor dat een eerste schifting in de input gemaakt is. Er kan in een ander configuratie bestand exact aangegeven worden waaraan input moet voldoen (server side en clientside controles kunnen beiden hieruit worden gegenereerd!)

Het komt er kortom op neer dat je niet weer bij elke actie compleet de security en validatie loopt te implementeren. Je maakt gewoon je actie. Die geef je rollen. Je maakt een bijbehorend formulier. Je geeft de restricties op van dat formulier en je hebt alles rond.

[zneek]

Jullie drijven af van de vraag jongens

Het ging om Object -> html -> Object

Wij gebruiken die HandleStringConverter zodat we altijd het volledige object kunnen construeren vanuit de request. Request komt bij binnen bij controller, controller laat het object in kwestie opbouwen door HandleStringConverter de html string versie (persoon=com.app.persoon:4) naar het Persoonsobject met id 4 (jantje) om te laten zetten. Dit gebeurt middels een call naar de PersoonDAO die op basis van het id met de methode loadAsEntity het object ophaalt (uit de db of uit de cache)

Op deze manier hoef ik dus nooit objecten in mijn sessie "te bewaren" om later in de functie er iets mee te doen. Mocht iemand de pagina bookmarken (app/verwijderPersoon?persoon=com.app.persoon:4) dan krijgt ie netjes een door de HandleStringConverter doorgegooide exception van de dao te zien (met een nette foutmelding in een foutmelding pagina): Te verwijderen persoon niet gevonden.

[ Voor 4% gewijzigd door zneek op 06-01-2005 23:26 ]

[Verwijderd]

Domweg de primaire sleutel waarmee het object geidenticifeerd wordt. Authorisatie en Authenticatie moeten uitwijzen of de actie gerechtvaardigd is.

[ Voor 3% gewijzigd door Verwijderd op 07-01-2005 00:46 . Reden: Tautologie verwijderd ]