[Java]Genereren van token voor action-checking

[Deathchant]

Hallo dames/heren,

Ik heb wat gezocht over dit onderwerp, maar vond helaas alleen resultaten over stringtokenizers. Dit moet ik echter niet hebben.

Ik werk met Java/Struts. Ik kan met mijn appicaties users laten inloggen.
Ingelogde users kunnen vervolgens alles acties uitvoeren, zoals save, delete, mutate.

Stel er komt een flapdrol en die wilt URL hacking doen (door direct naar een JSP pagina te gaan, zonder dat ie is ingelogd), dan moet natuurlijk een melding komen.

ik kan dit opvangen door in de JSP mbv een logic:present tag te checken of een user aanwezig is.

Maar stel de gebruiker heeft een save-action gedaan (opslag document) en deze drukt op de backknop en wilt dan nog eens versturen, dan gaat de gebruiker de request opnieuw uitvoeren, zonder data, waardoor een nullpointerexception optreedt.
Met behulp van de ingebakken struts saveToken(); kan ik bij elke actie controleren of het token wel geldig is.
Ik heb dit eerder gedaan, maar een enorm gezeik ermee gehad. Ik wist niet meer wanneer ik saveToken() en resetToken moest aanroepen. Bij de action deed ie het wel goed, bij de ander niet.

Dus ik wil zelf een soort token maken wat bovenstaand probleem oplost. Ik heb echter nog geen idee hoe ik dit moet doen. Ik heb een method generateToken(), maar weet nog niet wat ik daar in moet zetten. verder heb ik ook een isValidToken() method waarin ik ook nog niet weet wat daarin moet.
Ik moet het alweer snel binnen 2 dagen af hebben stricte doodlijnen hier. Kep af en toe echt de hulp van tweakers nodig

[Janoz]

Zou je het stukje actionmapping kunnen posten dat je gebruikt hiervoor? Ikzelf gebruik een clientside redirect (wat simpel te doen is door in je forward defenitie redirect="true" op te nemen) waardoor je met de forward en back knoppen niet op de daadwerkelijke save action terecht kunt komen.

mbt het direct aanroepen van de jsp's: In principe zouden je jsp's niet direct toegankelijk moeten zijn anders dan via een actie. Ikzelf doe dat ook niet, maar dat is wel de manier om dat goed af te vangen. Mijn persoonlijke mening is dat je geen nette foutmeldingen zou hoeven geven waneer iemand daadwerkelijk loopt te URL hacken. Je moet er alleen voor zorgen dat ze helemaal niks uit kunnen voeren. Door in je save/insert/mutate/edit actie zelf credetial checking op te nemen voorkom je dat iemand die acties uit kan voeren zonder dat hij dat zou mogen.

Het token mechanisme is eerder bedoeld om te voorkomen dat mensen een formulier op een andere site neerzetten die submit naar jouw site. Dit wordt wel eens gedaan om automatisch te kunnen stemmen op polls, spammen in gastenboeken of automatisch acounts aanmaken bij mailsites oid.

[Deathchant]

bedankt voor je uitgebreide info.

Ik heb in een afstudeer traject ditzelfde gemaakt, maar nu moet het voor het echt zeg maar. Voor het ministerie van VROM.
Ik heb op jouw verzoek en op andermans tips (van een ander topic van mij) deze redirect gebruikt.

Echter werkte dit niet, de gebruiker kon nog steeds dezelfde actie uitvoeren. Misschien dat je me kunt uitleggen hoe dat redirecten werkt.
Is dat ongeveer te vergelijken met javascript: document.location.replace?

De baas hier wilt graag dat ik gebruik maak van een generateToken en dat ik ervoor zorg dat de volgende actie een bepaalde token verwacht. Als de verwachte token niet aanwezig is, dan moet ik return mapping.findforward("failure") doen. Ik heb als global foward ingesteld dat hij altijd naar de failure-pagina gaat (error.jsp).

Edit: ik weet waar die redirect moet, maar welk stukje moet je zien dan? Maar het gaat zich erom dat de gebruiker niet een gecached formulier (wat ie dus al eerder verstuurd heeft) opnieuw kan versturen.
Ik weet dat ik niet hoef te discussieren over die backknop van IE, krijg je NOOIT helemaal goed verwerkt.

Edit2:

Java:

  <global-forwards>
    <forward name="failure" 
             path="/error.jsp"/>
  </global-forwards>

  <action-mappings>
    <action name="saveActionForm" 
            path="/SaveAction" 
            type="com.deathchant.SaveAction">
      <forward name="success" 
               path="/result.jsp"/>
    </action>
  </action-mappings>

[ Voor 101% gewijzigd door Deathchant op 26-07-2004 09:57 ]

[Gert]

'k Weet niet hoe struts werkt maar een manier is om elke actie een uniek id te geven. In een of ander config iets geef je dan volgorde van id's aan. Het uitgevoerde id sla je op in de sessie van de gebruiker nadat de actie is afgerond. In je handler die de save uitvoert kan maar 1 actie id aankomen, nl die het formulier heeft laten zien als iemand niet van de submit pagina komt zal het id nooit de juiste zijn.
Zo kan je ook voorkomen dat mensen van buitenaf submitten natuurlijk aangezien ze dan eerst een sessie moeten hebben.
Natuurlijk zou je ook gewoon de huidige actie in de sessie kunnen stoppen en kijken of die bij het submitten wel overeen komt met de actie die het formulier toonde.

[ Voor 15% gewijzigd door Gert op 26-07-2004 10:12 ]

[Janoz]

@Gert: Bij struts werkt dit automatisch. Hiervoor is idd dat generate token en is token valid.

@TS:

Afaik zou het generate token gebeuren moeten werken door bij de actie die het formulier genereerd de generate token uit te voeren. Omdat het een methode van Action is kun je dit niet door een losse JSP laten genereren. Ikzelf gebruik altijd een InitialInsert actie en een Insert actie. De eerste actie bereid het formulier voor en de tweede doet de daadwerkelijke actie op bv de DB. In die eerste actie gebruik je vervolgens generateToken(request). In de jsp neem je vervolgens het juiste formulier veld op en in de tweede actie kijk je met isTokenValid of het klopt. Bij een insert actie is het misschien wat ondduidelijk, Bij een edit actie is het wat duidelijker. De InitialEdit actie haalt alle gegevens uit de database en stopt deze in het actionForm. Dit wordt vervolgens gebruikt om het in het formulier de juiste gegevens in te vullen. http://struts.apache.org/....http.HttpServletRequest) Hier kun je een opsomming zien van de redenen waarom isValidToken niet werkt.

[ Voor 15% gewijzigd door Janoz op 26-07-2004 10:32 ]

[Deathchant]

Janoz schreef op 26 juli 2004 @ 10:30:
Afaik zou het generate token gebeuren moeten werken door bij de actie die het formulier genereerd de generate token uit te voeren. Omdat het een methode van Action is kun je dit niet door een losse JSP laten genereren.

ik snap niet wat je bedoelt met "de action die het formulier genereert".....
Een action hoeft toch geen formulier te genereren? Ik heb gewoon een JSP pagina waar 6 velden staan, waarin de gebruiker wat kan invullen. Dan wordt de saveaction uitgevoerd

Edit: ik snap wat je bedoelt.

ik heb het zo:
login.jsp -> loginaction -> home.jsp -> saveaction -> results.jsp


op home.jsp staan al die veldjes en dan wordt de saveaction uitgevoerd.
Maar ik kan alleen een token saven als mijn gebruiker is ingelogd, deze moet wel aan de gebruiker gekoppeld zijn. Wat zou ik dan moeten doen?
In die saveaction zou ik dan die isTokenValid moeten aanroepen, maar waar moet ik em dan genereren ?
En ik heb een hele rammel actions. Ik neem aan dat ik voor elke actie een nieuwe token moet maken?

[ Voor 45% gewijzigd door Deathchant op 26-07-2004 10:44 ]

[Janoz]

Hieronder heb ik een stukje uit een project van mij. Met dit project heb ik struts lopen uitvogelen en ben langzaam naar een structuur toegewerkt die later hier binnen dit bedrijf als standaard gaat werken. Het is nog niet helemaal uit gekristaliseerd en zodra 1.2 gereleased wordt zal de actionmapping flink worden versimpeld, maar het geeft je misschien een beetje een idee. Daarnaast ben ik ondertussen ook al weer afgestapt van de korte classnamen. Ik neem gewoon het 'formulier'-naam (in dit geval stylesheet) weer op.

code:

        <action path="/stylesheetretrievecss"
            name="idForm"
            type="nl.fundament.reporter.stylesheet.action.Retrieve">
            <forward name="Success" path="/layout/stylesheets/takercss.jsp"/>
        </action>
        <action path="/stylesheetlist"
            type="nl.fundament.reporter.stylesheet.action.RetrieveAll"
            scope="request"
            ><!-- roles="CREATOR,ADMIN,READER"  -->
            <forward name="Success" path="generator.stylesheet"/>
        </action>
        <action path="/stylesheetnew"
            type="nl.fundament.reporter.stylesheet.action.New"
            attribute="stylesheetForm"
            >
            <forward name="Success" path="generator.stylesheet.process"/>
        </action>
        <action path="/stylesheetedit"
            name="stylesheetForm"
            type="nl.fundament.reporter.stylesheet.action.Edit"
            scope="request"
            validate="false"
            >
            <forward name="Success" path="generator.stylesheet.process"/>
        </action>
        <action path="/stylesheetinsert"
            name="stylesheetForm"
            type="nl.fundament.reporter.stylesheet.action.Insert"
            scope="request"
            validate="false"
            >
            <forward name="Success" path="/action/stylesheetlist" redirect="true"/>
            <forward name="Error" path="/action/stylesheetlist" redirect="true"/>
        </action>
        <action path="/stylesheetupdate"
            name="stylesheetForm"
            type="nl.fundament.reporter.stylesheet.action.Update"
            scope="request"
            validate="false"
            >
            <forward name="Success" path="/action/stylesheetlist" redirect="true"/>
            <forward name="Error" path="/action/stylesheetlist" redirect="true"/>
        </action>
        <action path="/stylesheetdelete"
            name="stylesheetForm"
            type="nl.fundament.reporter.stylesheet.action.Delete"
            scope="request"
            validate="false"
            >
            <forward name="Success" path="/action/stylesheetlist" redirect="true"/>
            <forward name="Error" path="/action/stylesheetlist" redirect="true"/>
        </action>
        <action path="/stylesheetprocess"
            name="stylesheetForm"
            type="nl.fundament.util."
            scope="request"
            validate="false"
            input="generator.stylesheet.process"
            >
            <forward name="New" path="/action/stylesheetinsert"/>
            <forward name="Edit" path="/action/stylesheetupdate"/>
            <forward name="Delete" path="/action/stylesheetdelete"/>
            <forward name="Cancel" path="/action/stylesheetlist" redirect="true"/>
        </action>

Bij struts is het eigen,lijk de bedoeling dat je ALLES via een actie oproept. Nu heb je waarschijnlijk zelf zoiets als "daar kom je nu mee", maar achteraf is dat nog redelijk simpel in te bouwen. Door de standaard forward acties te gebruiken kun je in je action mapping voor elke jsp een actie maken. In je jsp's moet je vervolgens alle links vervangen door die acties. Als dat eenmaal klaar is heb je je hele applicatie via acties lopen. Dan kun je die standaard forward acties gaan vervangen door zelf geimplementeerde acties waarbij je bijvoorbeeld een token zet.

--

Je hoeft trouwens niet voor elke actie een nieuw token te maken. Het gegenereerde token wordt in je session gezet. Zodra je het in je formulier opneemt wordt het daaruit gelezen en bij het controleren wordt het daaruit gelezen. Er zijn twee methoden om het token te valideren. Degene met de extra boolean als parameter genereert automatisch een nieuw token voor de volgende keer.

[Deathchant]

bedankt voor je info. Ikzelf gebruik nu al 8 maanden struts. Ik heb Oracle 10g JDeveloper, waarin ik de struts-config.xml grafisch kan opbouwen. Dus die actionmappings zijn het probleem niet.

je zegt:

"Je hoeft trouwens niet voor elke actie een nieuw token te maken. Het gegenereerde token wordt in je session gezet. Zodra je het in je formulier opneemt wordt het daaruit gelezen en bij het controleren wordt het daaruit gelezen. Er zijn twee methoden om het token te valideren. Degene met de extra boolean als parameter genereert automatisch een nieuw token voor de volgende keer."

wanneer moet ik deze genereren (in welke action?) en wanneer wordt dit token "in het formulier opgenomen". En met het controleren ervan bedoel je het controleren van het token in de actie die wordt uit uitgevoerd indien je het formulier verstuurt?

trouwens, ik begin altijd met een jsp pagina he:

login.jsp -> loginaction -> home.jsp -> saveaction -> results.jsp

[ Voor 72% gewijzigd door Deathchant op 26-07-2004 11:15 ]

[Janoz]

Ergens in een action (desnoods de login) zou je generateToken(request) kunnen zetten. Dit zou genoeg moeten zijn. Na een edit actie kun je vervolgens dit token verversen door true mee te geven bij de validatie.

Na wat uitzoek werk zag ik in de FormTag class het volgende: http://struts.apache.org/...ormTag.html#renderToken() Een <html:form> tag heeft dus op 1 of andere manier een mogenlijkheid om automagisch het token in het formulier mee te renderen, ik heb echter geen idee of dit gebeurt zodra een token bekend is of dat daarvoor een speciale propertie nodig is in die tag.

[Deathchant]

Janoz schreef op 26 juli 2004 @ 11:55:
Ergens in een action (desnoods de login) zou je generateToken(request) kunnen zetten. Dit zou genoeg moeten zijn. Na een edit actie kun je vervolgens dit token verversen door true mee te geven bij de validatie.

Dat zou betekenen dat ik een Token maak terwijl de user niet ingelogd is. Hij moet hoe dan ook op een of andere manier gekoppeld zijn aan een sessie. Stel de gebruiker logt verkeerd in, dan is er wel al een token gemaakt. Dan kan deze alsnog een action uitvoeren. Ik check sowieso op username dus hij kan dan toch niks uitvoeren. Dan heeft de toke oplossing geen zin.

Janoz schreef op 26 juli 2004 @ 11:55:
Na wat uitzoek werk zag ik in de FormTag class het volgende: http://struts.apache.org/...ormTag.html#renderToken() Een <html:form> tag heeft dus op 1 of andere manier een mogenlijkheid om automagisch het token in het formulier mee te renderen, ik heb echter geen idee of dit gebeurt zodra een token bekend is of dat daarvoor een speciale propertie nodig is in die tag.

Dan zou ik deze klasse in de ActionForm moeten includen?

Edit: het lijkt mij dat dit token uit de sessie gehaald moet worden

[ Voor 4% gewijzigd door Deathchant op 26-07-2004 12:13 ]

[Janoz]

Je hebt een loginaction waarin de gebruiker daadwerkelijk wordt ingelogd. Hierin zou je na het valideren al een token kunnen genereren. Dat is simpel te doen door achteraan in die action voor de return nog ff generateToken te doen. Het token hoeft niet vlak voor het neerzetten van het formulier gegenereerd te worden, als het maar ergens wordt gedaan tussen het aanmaken van de sessie en het neerzetten van het formulier.

Ik heb het vermoeden dat de form tag nu automatisch een hidden field genereerd mits je natuurlijk gebruik maakt van <html:form>. Dit vermoeden komt doordat die methode in de formtag class staat. Het lijkt me dus absoluut niet de bedoeling dat die methode zelf aangeroepen moet worden. Deze wordt waarschijnlijk wel door de form tag uitgevoerd. Je zou het dus even moeten proberen

[Deathchant]

oke ik ga het proberen, dankjewel voor je reacties ik post wel weer als ik je hulp nodig heb

[momania]

Zoals Janoz het een beetje uitlegd heb ik het ook opgelost op m'n werk.

Ik heb voor elke pagina (jsp) een voorbereidende en een afhandelende action. Dat kunnen fysiek de zelfde actions zijn, maar ook echt 2 verschillende. Dit heb ik gedaan om eventuele uitbreidingen zo simpel mogenlijk toe te kunnen voegen. Of die uitbreidingen nu dus in de voorbereiding van een jsp moeten of in de afhandeling.

Hetgene dat je dus in je voorbereidene action altijd kan aanroepen is de saveToken() methode en bij de afhandelende methode doe je als eerste een isTokenValid().
Als je token dan goed is en je heb heel je afhandeling gedaan, doe je als laatste nog even een resetToken() en je token systeem werkt prima

Zo met 2 actions bij 1 jsp heb je direct ook altijd navigatie via je Actions en nooit direct naar een jsp of tile-set

[Deathchant]

waar moet je die resetToken dan doen?

je start je applicatie meestal altijd met een jsp pagina toch? Tenminste ik wel, ik begin met inloggen. Dus ik heb:

login.jsp -> LoginAction -> main.jsp -> SaveAction -> results.jsp

begrijp ik het goed als ik zeg dat ik, net voordat ik ga forwarden, de saveToken doe in de LoginAction en dat ik in de SaveAction aan het begin de isTokenValid() aanroep en alweer voor het forwarden moet resetten?

Of moet ik maar 1x het token saven voor de hele applicatie?

[Janoz]

De hele functionaliteit die je nodig hebt is dat voor elke keer dat een gebruiker een formulier submit je een ander token hebt. Het lijkt me dan ook redelijk logisch dat na elke keer controleren het token veranderd moet worden. Probeer te begrijpen wat de functies doen.
generateToken -> Stopt in de sessie op 1 of andere manier een uniek random iets dat vervolgens bij elk formulier (en eventueel link) wordt bijgeplakt.
isTokenValid -> vergelijkt een in het request meegestuurd token met degene die in de sessie staat
resetToken -> veranderd het token in de sessie.

Zodra je er dus voor zorgt dat ergens voordat je een formulier neerzet je een token genereerd en na elke keer dat je een formulier hebt gevalideerd het token reset lijkt het me te doen wat je wilt.
is

Common practice bij struts is, zoals ik eerder al zei, om je jsp's NIET toegankelijk te maken. Mijn applicatie begint bijvoorbeeld met een index.do actie.

[momania]

Deathchant schreef op 27 juli 2004 @ 09:08:
waar moet je die resetToken dan doen?

je start je applicatie meestal altijd met een jsp pagina toch? Tenminste ik wel, ik begin met inloggen. Dus ik heb:

login.jsp -> LoginAction -> main.jsp -> SaveAction -> results.jsp

begrijp ik het goed als ik zeg dat ik, net voordat ik ga forwarden, de saveToken doe in de LoginAction en dat ik in de SaveAction aan het begin de isTokenValid() aanroep en alweer voor het forwarden moet resetten?

Of moet ik maar 1x het token saven voor de hele applicatie?

Jouw rijtje van jsp -> Action zou in mijn geval zoeits worden:
PreLoginAction -> login.jsp -> LoginAction -> PreMainAction -> main.jsp -> SaveAction -> PreResultAction -> result.jsp

In dat geval kan je in elke Pre Action de saveToken aanroepen en in LoginAction en SaveAction bijvoorbeeld isTokenValid controleren en als de Action afgerond is roep je daar nog resetToken aan.

Zo verleg je de verantwoordelijkheden ook beter in je code. Het is nml. een beetje raar dat een SaveAction ook verantwoordelijk is voor het tonen van het resultaat.

[Janoz]

* Janoz maakt ff een kleine toevoeging aan het bovenstaande lijstje.....

PreLoginAction >> login.jsp --> LoginAction -> PreMainAction >> main.jsp --> SaveAction -> PreResultAction >> result.jsp

Met de volgende legenda
>> serverside forward (zoals in de strutsconfig gedefinieerd)
-> clientside forward (in strutsconfig met redirect="true")
--> gebruikers actie (submitten formulier of het drukken op een link)

[Deathchant]

de baas zegt dat ik me aan het rijtje moet houden....
dus gewoon login.jsp -> loginaction -> home.jsp -> etc....

dan gooi ik de saveToken() in de LoginAction net voordat ik forward.

en doe ik bij de SaveAction aan het begin een isTokenValid() aanroepen en dan net voordat ik forward een resetToken().

Mijn vraag is: als ik een resetToken() doe, moet ik dan weer een nieuwe saveToken doen ? zo ja, waar moet ik die dan doen?
Kep veel gezeik gehad ermee in vorige project, vandaar dat ik het vraag

EDit: hier mijn struts page flow: http://home.planet.nl/~barth076/StrutsPageFlow_2.png

[ Voor 76% gewijzigd door Deathchant op 27-07-2004 11:40 ]

[Janoz]

Dit soort vragen worden keurig in de javadoc beantwoord. Probeer de werking te begrijpen en dan wordt het ook duidelijk waneer welke methode aangeroepen zou moeten worden. Maak desnoods een kleine test applicatie met ene paar acties om precies te achterhalen hoe het werkt.

[Deathchant]

als ik er tijd voor heb zal ik dat doen ja. Maar even weinig tijd nu. Ik moet mijn hele afstudeertraject in 3 dagen doen nu. Kep alleen vandaag en

morgen nog om de globale structuur op te zetten.

Behalve de interactie met de business logic, het grafisch oppoetsen (want ik moet ook tabbladen gebruiken, maar mag geen gebruik maken van Swing, ik

moet het met java script doen).

Ik moet ook nog een sessioncontainer bijhouden, waarin ik allerlei beans inpleur door de hele sessie van een gebruiker.
Ik heb bijvoorbeeld een UserBean die ik vul (setters) en vervolgens in de sessioncontainer gooi). Nou moet ik op de JSP pagina die sessioncontainer

gebruiken. Specifieker nog, ik moet de userbean uit de sessioncontainer gebruiken.

Normaal kun je zeggen:

<logic:present name="userbean" scope="session"> en dan je bewerkingen.
Maar nu moet ik zeggen <logic:present name="sessioncontainer" scope="session">

maar ik moet de userbean daaruit hebben. Ik weet niet hoe ik dit object uit de sessioncontainer moet halen zonder java-code te gebruiken. Maar zoek

ik wel uit.

Die javadoc vind ik niet erg duidelijk btw:

saveToken(): Save a new transaction token in the user's current session, creating a new session if necessary.

resetToken(): Reset the saved transaction token in the user's session. This indicates that transactional token checking will not be needed on the

next request that is submitted.

resetToken() betekent dus niet dat het token verwijderd wordt, maar betekent dat je op de volgende actie (volgende request) geen controle hoeft te

doen.
Maar stel je wilt dat wel doen? dan hoef je geen reset aan te roepen.

Maar ik wil dat bij iedere actie gecheckt wordt of je wel van de vorige actie kwam. Ik snap het ff neit hoe het werkt?

[ Voor 26% gewijzigd door Deathchant op 27-07-2004 12:13 ]

[momania]

Simpeler dan dit is het niet uit te leggen:
De actie die voor de jsp zit doet een savetoken()
De actie die de submit van de jsp afhandeld controleerd de token via isTokenValid en doet dan als hij klaar is een resetToken().

Wil je dan op de volgende jsp weer met de tokens werken, dan wordt je afhandelende action dus ook de voorbereidende action voor je volgende jsp en moet je net na je resetToken() weer een saveToken() aanroepen.

[Deathchant]

ben de hele dag aan het proberen maar kom er niet uit
kep een SessionContainer die een userbean bevat. Deze bevat op zijn beurt een attribuut username.

de sessioncontainer zet ik in de sessie. Maar hoe kan ik met die logic: present en bean write tags de username uit de sessioncontainer halen? Vroeger deed ik gewoon die userbean in de sessie vlammen. Nu zit er dus nog die sessioncontainer tussen.....

Dat met die tokens werkt trouwens! ik had bij mijn vorig project blijkbaar ik elke action een saveToken gezet en ook een resetToken..............stom
Hij doet me op de home.jsp nu de volgende code erbij zetten als ik naar de source kijk:
<form name="goToViewActionForm" method="post" action="/GoToViewAction.do"><input type="hidden" name="org.apache.struts.taglib.html.TOKEN" value="b7060636e974e1af555f7c1792bfc57d">

[ Voor 20% gewijzigd door Deathchant op 27-07-2004 15:20 ]

[momania]

Waarom moet je die sessioncontainer bijhouden? Wat heeft het voor toegevoegde waarde? En wat voor type class is het het? (waar is het van afgeleid)

[Deathchant]

momania schreef op 27 juli 2004 @ 15:25:
Waarom moet je die sessioncontainer bijhouden? Wat heeft het voor toegevoegde waarde? En wat voor type class is het het? (waar is het van afgeleid)

sessioncontainer is een gewone class: public class SessionContainer
Ik moet dat van de baas. Ik werk samen met hem. Het doel is uiteindelijk dat meerdere beans beschikbaar zijn op een jsp pagina. We willen niet 6 beans in de sessie moeten vlammen. We pleuren die nu in sessioncontainer en die vlammen we in de sessie

In die sessioncontainer zitten 6 beans, onder andere een bean om userinfo bij te houden, eentje om bestandsinfo (van een geupload bestand) bij te houden, eentje om metakenmerken daarvan bij te houden etc.

[ Voor 16% gewijzigd door Deathchant op 27-07-2004 15:35 ]

[momania]

Ik zie nog steeds het nut niet om die beans dan in een aparte container vast te houden. Die container moet wel wat toevoegen aan functionaliteit om wat met die beans te doen, anders is het nutteloos.

Moet het persee een container worden, dan zou ik eerder een ArrayList of HasMap oid pakken als container, zodat je iig in je jsp met de logic:iterate door de items heen kan bladeren die er in zitten.

[Deathchant]

tja het gaat helaas niet anders. Kun je nou beter een vector of een hashmap gebruiken bij de iterate tag?

Maar goed. Je weet dus niet hoe ik de username kan laten afdrukken die ik uit die container pik he?

zo moet het
<bean:write name="userbean" property="username">

maar ik moet deze userbean eerst uit de sessioncontainer halen.

was er maar zoiets als:
<bean:write name="sessioncontainer" property="userbean.username">

[momania]

Deathchant schreef op 27 juli 2004 @ 15:51:
tja het gaat helaas niet anders. Kun je nou beter een vector of een hashmap gebruiken bij de iterate tag?

Maakt niet uit, zolang het maar onderdeel is van het Collection Framwork.
Ik zou dan alleen wel voor de AyyraList gaan oid. Vector is sowieso overhead omdat die synchronised is. Dat heeft hier geen nut.

was er maar zoiets als:
<bean:write name="sessioncontainer" property="userbean.username">

Dat heb ik wel eens ergens in documentatie terug zien komen, iig met een '.' er tussen.

[Deathchant]

ja, laat ik deze tip maar meenemen

Ik vind er trouwens niks over. Ik moet echt via die container die username attribuut verkrijgen van de userbean. Nog maar ff zoeken

offtopic:
Trouwens, hebben wij nou hetzelfde plaatje?

[Janoz]

Deathchant schreef op 27 juli 2004 @ 15:51:

was er maar zoiets als:
<bean:write name="sessioncontainer" property="userbean.username">

hmmm ... * Janoz krabt achter zijn oortje ...

Heb je <bean:write name="sessioncontainer.userbean" property="username"> ook geprobeerd? Er staat me namelijk iets bij dat dit mogenlijk is.

[ Voor 7% gewijzigd door Janoz op 27-07-2004 23:00 ]

[Verwijderd]

dat zou toch moeten werken??
name is de naam van de parameter in de scope (request, session, page, application,..) en als je die niet opgeeft gaat hij ze een voor een af.
adhv die 'name' wordt een bean opgezocht, en het propertie kan punten bevatten voor nested beans. Ik snap niet waarom het niet werkt, wat is de stacktrace? (wel even logic:notEmpty doen om NullPointers te vermijden)

[Deathchant]

dat met die tokens werkt. Maar stel ik heb in een action de resetToken aangeroepen en op volgende JSP is alweer een formulier?

login.jsp -> LoginAction: saveToken() -> home.jsp -> ViewAction: isTokenValid()....resetToken() -> view.jsp -> MainAction: ?????

kep de aanwijzingen opgevolgd van momania:

in de actie vóór je JSP de saveToken() aanroepen (zodat je op je JSP een hiddenfield met daarin het token krijgt), dan in de action ná de JSP checken op isTokenValid() en aan het einde van die action een resetToken() doen.

Maar de jsp wat daarna komt moet ook zo'n token bevatten. Moet ik dan na de resetToken opnieuw een saveToken doen, of moet ik de resetToken weglaten?

[Deathchant]

Janoz schreef op 27 juli 2004 @ 23:00:
Heb je <bean:write name="sessioncontainer.userbean" property="username"> ook geprobeerd?

Ja:

javax.servlet.jsp.JspException: Cannot find bean sessioncontainer.userbean in any scope

[ Voor 10% gewijzigd door Deathchant op 28-07-2004 10:13 ]

[Janoz]

Save maar een nieuwe, anders blijf je je hele sessie hetzelfde token gebruiken .

Heb je (mbt het sessioncontainer probleem) wel getters en setters gemaakt voor de userbean?

Waarschijnlijk wordt
<bean:write name="sessioncontainer" property="userbean.username">

vertaald naar
sessioncontainer.getUserbean().getUsername()

(let vooral ook op hoofdletters). Kijk anders even in de gecompileerde java bestanden die van de jsp's gemaakt zijn.


--Edit--
Html rechten zijn ook niet alles

[ Voor 6% gewijzigd door Janoz op 28-07-2004 14:54 ]

[Deathchant]

Janoz schreef op 28 juli 2004 @ 14:39:
Save maar een nieuwe, anders blijf je je hele sessie hetzelfde token gebruiken .

Heb je (mbt het sessioncontainer probleem) wel getters en setters gemaakt voor de userbean?

Waarschijnlijk wordt
<bean:write name="sessioncontainer" property="userbean.username">

vertaald naar
sessioncontainer.getUserbean().getUsername()

(let vooral ook op hoofdletters). Kijk anders even in de gecompileerde java bestanden die van de jsp's gemaakt zijn.

Ja idd!
javax.servlet.jsp.JspException: No getter method for property sessioncontainer.username of bean sessioncontainer


Ik heb het zo:
<bean:write name="sessioncontainer" property="ub.username">

dus dan zou ik een getter en setter moeten hebben getUb()

Ik heb deze getter, maar anders genoemd en andere parameters: getUserBean(request)

Maar hij verwacht een getter zonder parameter he?

[ Voor 11% gewijzigd door Deathchant op 28-07-2004 15:27 ]

[Deathchant]

trouwens dat met die tokens werkt niet meer nu.

Ik heb het volgende

j1 -> a1 -> j2 -> a2 -> j3 -> a3 -> j4 -> a4 -> j5 -> a5

met j voor JSP pagina en de a voor ACTION

ik heb gewoon in de actie vóór de jsp een savetoken gedaan en in de actie ná de jsp een isTokenValid(request, true) en net voordat ik forward, doe ik een saveToken(request).

De TRUE parameter geeft aan dat de token automatisch gereset wordt (aangezien dat toch in elke actie moet)

Dit alles gaat goed tot aan de 4e actie. Dan krijg ik ineens een invalid token. Dat had ik dus precies hetzelfde als bij het vorige project.

[ Voor 75% gewijzigd door Deathchant op 02-08-2004 09:18 ]

[Deathchant]

ik heb het nog eens geprobeerd, maar krijg het niet opgelost. Alles gaat goed tot aan de 4e actie die ik doe. Dan zegt ie ineens invalid token.
Het kan ook niet dat een token maar 4 acties geldig is. Bovendien save ik een nieuw token in elke actie.

Daarnaast heb ik een ander kleiner probleempje. Ik heb een ErrorBean waarin ik een property "error" heb die slechts een string representeert. Deze vul ik in de action en forward dan naar een error.jsp pagina. In de actie druk ik met system.out.println deze waarde af: niks aan de hand.
Maar als ik dan op de jsp <bean:write name="errorbean" prperty="error"> doe, dan doet ie het niet.

[EDIT: het probleempje met die error is al opgelost. Ik had de redirect=true nog aanstaan in struts-config.xml]

[ Voor 12% gewijzigd door Deathchant op 02-08-2004 09:23 ]

[Deathchant]

Janoz en Momania, het is al opgelost.
De token wordt middels een hidden field doorgegeven. Ik had op de 4e jsp pagina alleen maar <html:link> staan. NIET in een form. Om een hiddenfield te maken heb je uiteraard een form nodig. helemaal niet meer bij stil gestaan.

Wat een toeval dat het wederom de 4e jsp pagina is (bij afstudeertraject ook al).
Dus voor degene die dit lezen: indien je met struts token werkt en je wilt in elke action controleren op token, dan moet je in elke jsp pagina een form hebben.

Heb je meerdere <html:link> tags waarbij verschillende actions horen, maar dan een form per link aan.

Verander

Java:

<html:link href="/SomeAction">SomeAction</html:link>

in

Java:

<html:form action="/SomeAction" name="form1"><html:button property="form1submit" onclick="javascript:document.form1.submit()"/>

dit dan voor elke link die je hebt

[ Voor 8% gewijzigd door Deathchant op 02-08-2004 12:43 ]

[Janoz]

Deathchant schreef op 02 augustus 2004 @ 12:42:
Janoz en Momania, het is al opgelost.
De token wordt middels een hidden field doorgegeven. Ik had op de 4e jsp pagina alleen maar <html:link> staan. NIET in een form. Om een hiddenfield te maken heb je uiteraard een form nodig. helemaal niet meer bij stil gestaan.

Wat een toeval dat het wederom de 4e jsp pagina is (bij afstudeertraject ook al).
Dus voor degene die dit lezen: indien je met struts token werkt en je wilt in elke action controleren op token, dan moet je in elke jsp pagina een form hebben.

Dit kun je makkelijker doen door gewoon het attribuut transaction="true" in je link te gebruiken. Zie daarvoor ook http://struts.apache.org/userGuide/struts-html.html#link .

[ Voor 20% gewijzigd door Janoz op 03-08-2004 09:15 ]

[Deathchant]

hey Janoz. Bedankt voor je moeite! En bedankt voor de simpele oplossing. Ik doe altijd alles moeilijk . Ben jij struts guru ofzo ?

[-FoX-]

Die tokens worden dus gebruikt voor het checken of een actie reeds is uitgevoerd, ook handig voor wizard-like pagina's.

Ik ga me er eens op toeleggen, want voor mijn openstaand project kan dit zéker gebruikt worden..

[Janoz]

mwah, ik werk er zelf al meer dan een jaar mee. Binnen ons bedrijf heb ik een redelijk grote applicatie ontwikkeld en deze als 'testbed' gebruikt voor wat nu eigenlijk ene handige structuur is. Dit gebruiken we nu ook voor al onze andere applicaties hier. Ik ben hier zelfs al bijna een keer weg-'gekocht' door een ander bedrijf dat een struts-kenner nodig had.. Maar of je dan een struts guru bent weet ik niet

[Deathchant]

Janoz schreef op 03 augustus 2004 @ 13:03:
mwah, ik werk er zelf al meer dan een jaar mee. Binnen ons bedrijf heb ik een redelijk grote applicatie ontwikkeld en deze als 'testbed' gebruikt voor wat nu eigenlijk ene handige structuur is. Dit gebruiken we nu ook voor al onze andere applicaties hier. Ik ben hier zelfs al bijna een keer weg-'gekocht' door een ander bedrijf dat een struts-kenner nodig had.. Maar of je dan een struts guru bent weet ik niet

Wat doe je voor werk dan ? (aannemend dat dit van tweakers je hobby is)
Ik werk nu ook alleen maar met J2EE en struts. Vanaf februari tot nu. Ik had RUK verstand van Java, laat staan van Struts. Maar java is best makkelijk vind ik. Zijn vooral weetjes die je eigenlijk in je hoofd moet hebben (zoals class casting) en .toString enzo.
En je moet weten wat beter is voor geheugen of cpu

Al dat gecast word ik wel ziek van eigenlijk Wil je een int als string laten afdrukken...........pfffffffff..............

[-FoX-]

Naar mijn indruk zitten er eigenlijk ook niet zoveel struts developers op dit forum, of ben ik mis?

[Janoz]

Mwah, wel een paar, maar het zijn vooral mensen die ermee aan het stoeien zijn.


@deathchant : Dat casting gebeuren zal straks een stuk minder zijn met 1.5. en voor mijn beroep :

[momania]

Janoz schreef op 03 augustus 2004 @ 13:24:
Mwah, wel een paar, maar het zijn vooral mensen die ermee aan het stoeien zijn.

Ikke niet stoeien

Ik gebruik het nu ook al bijna weer een jaartje. Wel eerste project ook hier en moest het zelf leren met behulp van google en online documentatie. Een goede java achtergrond is iig wel handig, daar werk ik nu zo'n 3,5 jaar mee. Anyway is struts leuk, maar je moet er echt wel de tijd voor nemen om veel te lezen en veel te testen/proberen. Als je die tijd niet hebt of krijgt kan het erg moeilijk worden om echt een goed beeld te krijgen van het geheel dat struts is (aangezien het _mega_ uitgebreid is)

[misfire]

Die Struts tokens ben je nu al uit dankzij de handige tip van Janoz (ik deed het ook altijd met forms).

was er maar zoiets als:
<bean:write name="sessioncontainer" property="userbean.username">

Er is ook zoiets, namelijk EL in JSTL, dat werkt zo:
<c:out value="${sessioncontainer.userbean.username}"/>

Zie hier voor een paar voorbeelden. JSTL maakt een hoop dingen in JSP gemakkelijker.

Al dat gecast word ik wel ziek van eigenlijk Wil je een int als string laten afdrukken...........pfffffffff..............

Om een int als een string af te laten drukken hoef je helemaal niet te casten. Als je een int aan een String concateneert dan wordt de conversie automatisch gedaan. Als je een int direct print in JSP dan wordt de conversie ook automatisch gedaan door de JSP compiler. Als je een wat ingewikkelder stukje tekst in elkaar wilt draaien dan is het handig om de MessageFormat klasse te gebruiken. Helaas zal pas bij Java 5 autoboxing ingevoerd worden, dus je moet dan wel zelf boxen, maar dat is iets anders als casten.

[Verwijderd]

-FoX- schreef op 03 augustus 2004 @ 13:18:
Naar mijn indruk zitten er eigenlijk ook niet zoveel struts developers op dit forum, of ben ik mis?

toch wel één extra
Waar ik net geen jaar geleden begonnen ben werkten ze reeds met Struts in een alfa phase (er was toen geen andere MVC oplossing). Een goeie 3 jaar later werken we nog steeds met Struts aan dezelfde webapplicatie en zijn er geen klachten
Ik ben ook aan het hele Struts - J2EE gebeuren begonnen met heel weinig java ervaring, maar Struts is tamelijk snel aangeleerd vind ik (zeker in vergelijking met EJBs enzo). (de finesses komen steeds iets later, maar toch).

Zijn er eigenlijk mensen die positieve ervaringen hebben met andere MVC frameworks? Negatieve opmerkingen over struts/tiles? (daar ben ik wel nieuwsgierig naar:))

[Peetman]

Ik ben nu ook al weer zo'n half jaar met Struts bezig op het werk. Niet full-time, meer tussendoor. Ik wil er zeker meer van weten en de verwachting is hier dat we veel meer met J2EE gaan doen.
Ook ik ben het aan het leren vanuit een achtergrond zonder Java kennis, wel C++, dus OOP is me niet vreemd.

Edit:
Handig topic dit trouwens, kan ik binnenkort zeker nog een keer gebruiken.

[ Voor 14% gewijzigd door Peetman op 03-08-2004 14:20 ]

[Janoz]

Het enige dat ik met tiles mis is dat je key's ipv values op kunt geven. Mijn applicatie was helemaal i18n, maar ik had in mijn tile definitions de pagina titel staan. Aangezien die allemaal in het nl waren had ik daar voor de spaanse versie niks aan. Ik heb alles moeten vervangen door een algemene titel omdat ik dus niet i18n 'aware' keys in mijn tiles-def kon gebruiken.


----

Owh, mijn grootste ergenis vergeet ik nog. Het feit dat de configuratie niet zomaar opnieuw ingelezen wordt bij het opnieuw deployen. Vooral met dynaactionforms heb ik hier last van. Dit is uiteraard meer een probleem tijdens het developen, maar irritant is het wel.

[ Voor 28% gewijzigd door Janoz op 03-08-2004 14:16 ]

[Verwijderd]

Janoz schreef op 03 augustus 2004 @ 14:13:
Het enige dat ik met tiles mis is dat je key's ipv values op kunt geven. Mijn applicatie was helemaal i18n, maar ik had in mijn tile definitions de pagina titel staan. Aangezien die allemaal in het nl waren had ik daar voor de spaanse versie niks aan. Ik heb alles moeten vervangen door een algemene titel omdat ik dus niet i18n 'aware' keys in mijn tiles-def kon gebruiken.

tiens, die snap ik niet helemaal.
Als je een attribuut put naar een tile kun je die toch in bean:message als key stoppen? Dan heb je toch je key naar je title?
Ik denk dat deze oplossing te simpel is en ik dus het probleem niet goed begrijp

(conf files heb ik nog nooit last mee gehad met een nieuwe deploy... maar ik gebruik ook geen dynaactionforms, ik schrijf die gewoon uit....

[Janoz]

Misschien heb ik het al tijden over het hoofd gezien, maar hoe combineer ik een <tile:put met een <bean:message. Iemand heeft hier zelf al eens geoppert om gewoon een jsp te includen waarin enkel de bean message stond.

[momania]

Die title valt idd niet uit een property file te halen, daar ben ik zelf ook al een keer tegen aan gelopen en is iid een groot gemis van de tiles.

[Verwijderd]

Janoz schreef op 05 augustus 2004 @ 16:14:
Misschien heb ik het al tijden over het hoofd gezien, maar hoe combineer ik een <tile:put met een <bean:message. Iemand heeft hier zelf al eens geoppert om gewoon een jsp te includen waarin enkel de bean message stond.

ehm, ik zit nu niet op't werk (congé payé ) maar ik denk dat het zoiets is:

<tiles:useAttribute classname="java.lang.String" id="messageKey" name="nameFromTileDefinition" /> <%-- default scope == page, ideal!--%>

<bean:message key="<%= messageKey %>" />

of

<bean:message name="messageKey" scope="page" />

en ik heb het niet getest, maar dat zou moeten werken... (ik gebruik die code zelden omdat wij ook voor zo'n klein deel een common tile hebben)

[google helpt ook blijkbaar:]
http://www.mail-archive.c....apache.org/msg22854.html

[ Voor 15% gewijzigd door Verwijderd op 05-08-2004 18:57 . Reden: googelen ]