You are not authorized to perform that operation - agent

Afhængig af hvilken version af serveren du har, så kan der være forskellige problemer. Når du håndkører, så kører du agenten som dig selv, så er der vistnok ingen problem.

Ved baggrundsagenter er der mange ting at tage hensyn til:
* Hvis databasen du slår op i ligger på en anden server, så er det normalt ikke muligt at slå op i en baggrundsagent.
* Du skal have lov til at køre baggrundsagenter. Dette angives på sikkerhedsektionen på serverdokumentet.
* Hvis du har en R5 eller ældre server, så kører agenten "som server", mens den på en R6 eller nyeere kører "som dig". Det kan også have indflydelse, f.eks. vedr. opslag på databaser (angiveler i ACL).

oops, jeg så lige at alt ligger på samme server, så kan det være at først punkt ikke gælder, men så alligevel. Hvis du angiver at DBLookup skal slå op i databasen på ServerXYZ, så laver du et ulovligt serveropslag.

Du kan angive server-parameteren via funktionen
@DbName[1] (version 6>) eller
@Subset(@DbName; 1) for 5<)

Hvis agenten afvikles på en server, vil ovenstående parameter angive "", hvilket er ensbetydende med "lokal", altså samme som den aktuelle database.

Serveren er ver. 5. og jege mindes ikke at have haft problemet før. I lookup har jeg brugt databasen unikke ID istedet for server:filenname.

ACL'en indeholder (standard) serveren som manager.

Kan hele miseren have noget med signering at gøre??

JEK

Prøv at vise koden.

Sidder lige og kæmper med undervisningsministeriets naturfagsprøve på nettet - der absolut kun kan køre på IE6.0 - så alle os firefox-bruger på skoler med OpenSource systemer er helt lost. Synd for eleverne og skolerne med godt for Bill Gates - når ministeriet på den måde yder indirekte offentlig støtte til et "monopol".

Vender tilbage når jer er tilbage på min domino-stol :-)

JEK

FIELD Weekendplan:=@DbLookup( Notes : "NoCache" ; "C12570D2:004AEC26" ; "(Weekendplan_export)" ; @Name([CN];DominoBruger) ; 2 );SELECT @All

Jeg ved ikke, men
  @DbLookup( Notes : "NoCache" ;
ville jeg erstatte med
  @DbLookup( "NoCache" ;
Men det burde ikke betyde noget...

Prøv at erstatte replikaid med fysisk filplacering ... bare for at debugge ... rart at vide om "noget" virker

Fysisk placering - giver nyt (overraskende!!) svar "File does not exist"

kode?

Jeg plejer at anvende noget der ligner følgende:


_server := @Subset( @DbName; 1);
_path := "her kommer stien, husk at angive \\ hvor du normalt vil angive \";
_view := "(Weekendplan_export)";
_key := @Name([CN];DominoBruger);
_look :=@DbLookup( "NoCache" ; _server : _path; _view ; _key ; 2 );
_debugerror1 := @Text(_look);
_debugerror2 := "";
FIELD Weekendplan := @If(@IsError(_look); _debugerror1; _look);
SELECT @All

Det gør det nemmere at debugge.

God idé den vil jeg huske - Gjort

resultat:

The necessary external database driver cannot be located

undskyld, dblookup skal hedde:
@DbLookup( "" : "NoCache" ;

Ja, den har jeg også fanget... nu kører den når jeg tvangskører den med nedenstående kode. Jeg vender lige tilbage når den har kørt om et par minutter...

_server := @Subset( @DbName; 1);
_path := "Data\\Intranet.nsf";
_view := "(Weekendplan_export)";
_key := @Name([CN];DominoBruger);
_look :=@DbLookup( Notes:"NoCache" ; _server : _path; _view ; _key ; 2 );
_debugerror1 := @Text(_look);
_debugerror2 := "";
FIELD Weekendplan := @If(@IsError(_look); _debugerror1; _look);
SELECT @All

Så er vi tilbage ved udgangspunktet...den slår godt nok op men bliver afvist som uaftoriseret...

Så check serverdokumentet og sikkerhed. Står der noget om dig og afvikling af baggrundsagenter?

Hvad med intranet.nsf og ACL, hvad er ACL sat til for Serveren? Brugertypen?

Pas - det er som det skal være...

Jeg kan godt køre agenten internt i den base jeg forsøger at læse i...men åbenbart ikke på tværs..

Serveren må evt. ikke stå som brugertype "Server", men "Unspecified". Hvis agenten kører, så vil den blive opfattet som en "klient" og så vil serveren måske blive afvist pga. uoverenstemmelse i brugertypen.

Prøv at sætte Default rettigheden til læser. Så kan vi se om det er ACL der driller.

Bingo!!

Jeg havde oprindeligt sat Default rettigheder til "no access" med Reader kører den som den skal!!

Jeg er ikke nogen haj på det her område...men jeg forstår ikke helt at serveren - som jo har manager-rettigheder - tilsyneladende ikke kan over-rule default-adgangen.

Basen vi kigger i bruges som ståsted for vores intranet (www.pepost.dk) og jeg mente egentlig det var mest klogt at begrænse adgangen mest muligt, men jeg kan godt nu jeg bevæger mig lidt ned i materien, se at det ikke rigtig giver mening af have en default adgang der er skrappere end den der er givet til anonymous.

Det skyldes vistnok at du har sat serverens brugertype i ACL til Server. Det betyder, at den kun kan tilgå databasen, hvis den f.eks. ligger på en anden server, via replikering etc, dvs ved deciderede serverhandlinger. Når du laver en agent, så fungerer agenten som en klient/person.

I version 6> har de ændret afviklingen af baggrundsagenter, så de kører med identiteten af den person som sidst har rettet i agenten. Dvs at agenter, som du afvikler manuelt, sandsynligvis kører præcis på samme måde i baggrunden på serveren.

Det der med brugertypen blev indført i version 4 tror jeg, for at undgå at personer kunne sætte sig ud ved serveren og tilgå databaser lokalt, og på den måde snige sig ind i dokumenter og databaser som de normalt ikke har adgang til. Så ved at sætte brugertypen i ACL til "Server" så kan man sikre at det kun er serveroperationer som kommer igennem. Hvis man som serverklient tilgår databasen så findes man ikke i ACL (pga manglende match af navn&brugertype). Hvis du sætter serverens brugertype i ACL til "Unspecified", så vil den opfattes som et wildcard *, altså navn&*  (hvis du forsår hvad jeg mener). Når der ikke er match, så går man tilbage til DEFAULT. Derfor virker det når du sætter DEFAULT til READER.

Men på en måde har du ret i, at det ikke kan betale sig at have en DEFAULT der er mindre end Anonymous.

Ja så fik jeg da set på jeres hjemmeside og fandt da også dig.

Så skal du vel have nogen point - jeg har fået løst problemet. Og så må jeg se at få råd til en opgradering snart..

Du kan altså løse det ved at ændre "Brugertypen" fra "Server" til "Unspecified" i databasens ACL-registrering for servernavnet.