Header(remote_user) soms geen waarde
14 views
Skip to first unread message
Jauko
Jul 9, 2009, 3:10:17 AM7/9/09
to Smartsite5
Voor formulieren worden enkele gebruikers gegevens automatisch
ingevuld aan de hand van header/user macros.
Om onbekende reden (tot nu toe) vallen deze macros nog wel eens om.
Metname met Header(remote_user) krijg ik net zo vaak wel als niet
gegevens terug.
Maakt het nog uit of ik gebruik maak van "user(LoginName)" in plaats
van "Header(remote_user)". De header macro valt veel vaker weg, dan de
"user(fullname)" macro nml?
ingevuld aan de hand van header/user macros.
Om onbekende reden (tot nu toe) vallen deze macros nog wel eens om.
Metname met Header(remote_user) krijg ik net zo vaak wel als niet
gegevens terug.
Maakt het nog uit of ik gebruik maak van "user(LoginName)" in plaats
van "Header(remote_user)". De header macro valt veel vaker weg, dan de
"user(fullname)" macro nml?
Johan Kanselaar
Jul 9, 2009, 5:29:42 AM7/9/09
to Smart...@googlegroups.com
User(fullname) is het smartsite object dat bestaat wanneer de pagina restricted is. Kan zijn dat er geen fullname is maar het user object zou er wel moeten zijn en je zou kunnen checken of er een userid is want dat is bijvoorbeeld het geval wanneer iemand (nog) niet ingelogd is.
Header(remote_user) hangt af van datgene wat Internet Explorer / Windows meegeeft in zijn request aan IIS, en dat is zeker veel variabeler. Meestal staat daar de username in van hoe iemand ingelogd is op zijn eigen computer of het netwerk. Dat hoeft niet perse overeen te komen met een username die bij smartsite ook bekend is, behalve dan wanneer Windows/LDAP security correct gekoppeld is.
Dus ja dat maakt zeker uit :)
Johan
Header(remote_user) hangt af van datgene wat Internet Explorer / Windows meegeeft in zijn request aan IIS, en dat is zeker veel variabeler. Meestal staat daar de username in van hoe iemand ingelogd is op zijn eigen computer of het netwerk. Dat hoeft niet perse overeen te komen met een username die bij smartsite ook bekend is, behalve dan wanneer Windows/LDAP security correct gekoppeld is.
Dus ja dat maakt zeker uit :)
Johan
2009/7/9 Jauko <ja...@hotmail.com>
Jauko
Jul 9, 2009, 6:32:28 AM7/9/09
to Smartsite5
User(fullname) en/of userid zijn er en kan ik gebruiken. Een enkele
keer bij bijvoorbeeld refresh van pagina wilt de var macro soms niet
gevonden worden en geeft foutmelding:
Error running Macro 'var': User object not available
Bij eenzelfde refresh v/e pagina valt echter veel vaker de header
macro om (zonder foutmedling) en geeft niks meer terug.
p.s. bij elke nieuwe browsersessie van de gebruiker worden rechten
gecheckt in Active directory (heb inmiddels begrepen dat dit maatwerk
is)
Ik ga het proberen met user(LoginName), thnx!!!
keer bij bijvoorbeeld refresh van pagina wilt de var macro soms niet
gevonden worden en geeft foutmelding:
Error running Macro 'var': User object not available
Bij eenzelfde refresh v/e pagina valt echter veel vaker de header
macro om (zonder foutmedling) en geeft niks meer terug.
p.s. bij elke nieuwe browsersessie van de gebruiker worden rechten
gecheckt in Active directory (heb inmiddels begrepen dat dit maatwerk
is)
Ik ga het proberen met user(LoginName), thnx!!!
Johan Kanselaar
Jul 9, 2009, 7:03:26 AM7/9/09
to Smart...@googlegroups.com
Je kan controleren op {page:restricted} of page(restricted), wanneer die 1 is dan is het userobject beschikbaar anders niet. Dat is de foutmelding die je krijgt bij restricted=0.
Dat klopt de header object geeft bijna nooit een foutmelding maar gewoon een lege string terug. (als je een juiste variable ophaald als "remote_user", wanneer bijv "remotser" zou opvragen krijg je wel een fout.)
Dat klopt, dat is standaard wanneer je koppeling hebt met een externe security zoals bijv de maatwerk active directory, of de standaard windows authentication. De rechten worden aan het begin van de sessie opgeslagen in de smartsite db en tijdens de rest van de sessie hieruit opgevraagd omdat dat sneller is dan iedere keer het ophalen uit de Active Directory.
Succes!
Johan
Dat klopt de header object geeft bijna nooit een foutmelding maar gewoon een lege string terug. (als je een juiste variable ophaald als "remote_user", wanneer bijv "remotser" zou opvragen krijg je wel een fout.)
Dat klopt, dat is standaard wanneer je koppeling hebt met een externe security zoals bijv de maatwerk active directory, of de standaard windows authentication. De rechten worden aan het begin van de sessie opgeslagen in de smartsite db en tijdens de rest van de sessie hieruit opgevraagd omdat dat sneller is dan iedere keer het ophalen uit de Active Directory.
Succes!
Johan
2009/7/9 Jauko <ja...@hotmail.com>
Jauko
Jul 9, 2009, 7:50:43 AM7/9/09
to Smartsite5
Bedankt voor je reactie Johan.
Heb jij misschien enig idee waarom op eenzelfde pagina de header macro
de ene wel en andere keer niet werkt? Op deze manier heb ik er niet zo
heel veel aan ;)
gr.
Jauko
Heb jij misschien enig idee waarom op eenzelfde pagina de header macro
de ene wel en andere keer niet werkt? Op deze manier heb ik er niet zo
heel veel aan ;)
gr.
Jauko
Johan Kanselaar
Jul 9, 2009, 9:17:50 AM7/9/09
to Smart...@googlegroups.com
Omdat op dat moment een bepaalde user niet correct ingelogd is in het netwerk maar toch kan surfen? De Header macro werkt wel, maar de Remote_User wordt niet meegegeven op sommige momenten. Wat daar de oorzaak van is kan heel divers zijn: Windows van de client, al dan niet correct ingelogd zijn van de client, de IE van de client, IIS op de webserver. Dus de header informatie is altijd al inherent onbetrouwbaar. Als je op basis van Header(remote_user) moet werken, dan moet je ook dus controleren of die leeg is, zo ja dan gewoon toegang weigeren en als die wel gevuld is dan kijken wat die user wel of niet mag.
Johan
Johan
2009/7/9 Jauko <ja...@hotmail.com>
Jauko
Jul 13, 2009, 3:48:08 AM7/13/09
to Smartsite5
Bedankt voor je informatie en hulp Johan. Ik ga de user(LoginName)
vanaf nu gebruiken :)
gr Jauko
vanaf nu gebruiken :)
gr Jauko
Jauko
Jul 13, 2009, 8:43:58 AM7/13/09
to Smartsite5
dit blijkt toch ook weer niet goed te gaan. voor 50% van de gebruikers
werkt de user(loginname) macro, voor de andere helft niet??
(restricted geeft trouwens 1 bij mij, maar dat zal ook wel 50%-50%
zijn dan).
Nog suggesties, anders wordt het gewoon een invuloefening voor alle
gebruikers :)
thnx
werkt de user(loginname) macro, voor de andere helft niet??
(restricted geeft trouwens 1 bij mij, maar dat zal ook wel 50%-50%
zijn dan).
Nog suggesties, anders wordt het gewoon een invuloefening voor alle
gebruikers :)
thnx
Johan Kanselaar
Jul 13, 2009, 10:51:24 AM7/13/09
to Smart...@googlegroups.com
Jauko,
Waarschijnlijk moet je dit probleem niet alleen maar in je code oplossen. Security is security, daar kan je moeilijk omheen.
Je moet uitzoeken waarom sommige users wel ingelogd zijn en andere niet. Dat zou niet moeten kunnen als de pagina beveiligd is. Een pagina is restricted dus iedereen is ingelogd of je hebt geen toegang. Als dat niet zo is dan is heel je beveiliging mank natuurlijk.
Wanneer mensen op het intranet automatisch ingelogd worden, dan hangt dat af van hun internet explorer instellingen. In IE dient in de internet opties "Automatically login into intranetzone" aan te staan om gebruikers automatisch te laten inloggen op het intranet. Is dat niet het geval dan worden ze niet ingelogd.
Als jou pagina gewoon publiek is (dus eigenlijk niet beveiligd) maar interne mensen kunnen er ook op terecht komen terwijl ze ingelogd zijn op een ander deel van de site dan moet je gewoon eerste controleren of username/loginname etc leeg zijn of niet. Wanneer loginname/username/etc onbekend dan render je de pagina alsof niemand ingelogd is, en anders doe je net dat kleine beetje anders wanneer iemand ingelogd is. Je moet beide mogelijkheden afvangen.
Of je moet instellen op je pagina dat mensen alleen maar op de pagina terecht mogen komen wanneer ze ingelogd zijn.
Het kan ook zo zijn bij de ene helft user(loginname) werkt en bij de andere helft header(Remote_User). Of dat een gewenste situatie is weet ik niet, maar dit kan eventueel zo ingesteld zijn in de beveiligings instellingen.
Ik heb niet het idee dat er wat mis gaat, maar dat je zoveel mogelijk op verschillende computers met verschillende gebruikers moet testen en alle situaties in je code moet afvangen en in je code bepaald wat er in die situatie moet gebeuren.
Succes!
Johan
Waarschijnlijk moet je dit probleem niet alleen maar in je code oplossen. Security is security, daar kan je moeilijk omheen.
Je moet uitzoeken waarom sommige users wel ingelogd zijn en andere niet. Dat zou niet moeten kunnen als de pagina beveiligd is. Een pagina is restricted dus iedereen is ingelogd of je hebt geen toegang. Als dat niet zo is dan is heel je beveiliging mank natuurlijk.
Wanneer mensen op het intranet automatisch ingelogd worden, dan hangt dat af van hun internet explorer instellingen. In IE dient in de internet opties "Automatically login into intranetzone" aan te staan om gebruikers automatisch te laten inloggen op het intranet. Is dat niet het geval dan worden ze niet ingelogd.
Als jou pagina gewoon publiek is (dus eigenlijk niet beveiligd) maar interne mensen kunnen er ook op terecht komen terwijl ze ingelogd zijn op een ander deel van de site dan moet je gewoon eerste controleren of username/loginname etc leeg zijn of niet. Wanneer loginname/username/etc onbekend dan render je de pagina alsof niemand ingelogd is, en anders doe je net dat kleine beetje anders wanneer iemand ingelogd is. Je moet beide mogelijkheden afvangen.
Of je moet instellen op je pagina dat mensen alleen maar op de pagina terecht mogen komen wanneer ze ingelogd zijn.
Het kan ook zo zijn bij de ene helft user(loginname) werkt en bij de andere helft header(Remote_User). Of dat een gewenste situatie is weet ik niet, maar dit kan eventueel zo ingesteld zijn in de beveiligings instellingen.
Ik heb niet het idee dat er wat mis gaat, maar dat je zoveel mogelijk op verschillende computers met verschillende gebruikers moet testen en alle situaties in je code moet afvangen en in je code bepaald wat er in die situatie moet gebeuren.
Succes!
Johan
2009/7/13 Jauko <ja...@hotmail.com>
Jauko
Jul 14, 2009, 4:50:43 AM7/14/09
to Smartsite5
Ik heb nog eens gekeken naar restricted en dat staat toch niet overal
goed.
Ik dacht dat wanneer smartsite aangeeft dat er browserechten staan op
een bepaald item, in de dbase voor dit item restricted op 1 staat.
Dit blijkt niet het geval. Ik zal misschien het verkeerd begrepen
hebben. In sommige gevallen staat het op 1 en soms op 0.
Het is wel zo, dat wanneer ik opnieuw browserechten zet, alle
onderliggende items (behalve folders) op 1 worden gezet.
goed.
Ik dacht dat wanneer smartsite aangeeft dat er browserechten staan op
een bepaald item, in de dbase voor dit item restricted op 1 staat.
Dit blijkt niet het geval. Ik zal misschien het verkeerd begrepen
hebben. In sommige gevallen staat het op 1 en soms op 0.
Het is wel zo, dat wanneer ik opnieuw browserechten zet, alle
onderliggende items (behalve folders) op 1 worden gezet.
Johan Kanselaar
Jul 14, 2009, 4:55:00 AM7/14/09
to Smart...@googlegroups.com
Ja precies, dat hoort idd niet te kunnen dat er browserechten op gedefinieerd staan maar de pagina niet restricted is....
Opnieuw rechten zetten is dan idd de oplossing. Als het goed is kan je bij dat rechten zetten ook aanvinken "include all children / inclusief alle kinderen" zodat ie dan ook op alle daaronder gelegen folders de rechten zet en die dan ook restricted maakt.
johan
Opnieuw rechten zetten is dan idd de oplossing. Als het goed is kan je bij dat rechten zetten ook aanvinken "include all children / inclusief alle kinderen" zodat ie dan ook op alle daaronder gelegen folders de rechten zet en die dan ook restricted maakt.
johan
2009/7/14 Jauko <ja...@hotmail.com>
Jauko
Jul 14, 2009, 5:50:39 AM7/14/09
to Smartsite5
Bedankt voor de bevestiging. Ik had inderdaad ook nog de mogelijkheid
voor ...'and all subfolders'.
gr Jauko
voor ...'and all subfolders'.
gr Jauko
Reply all
Reply to author
Forward
0 new messages