Cadet 1st Class
Cadet 1st Class
1237 views

getProxyAccessListRequest causing program termination

I'm using GroupWise 2014 R2 and calling getProxyAccessListRequest as follows:

getProxyAccessListRequest *proxyReq = new getProxyAccessListRequest;
getProxyAccessListResponse *proxyResp = new getProxyAccessListResponse;

soapHeaders->Send(sess);
proxyResp = gwSoap->getProxyAccessListRequest(proxyReq);

If there are no proxy entries, no problem.
If there is only <All User Access> without rights, no problem.
If I add an entry without rights, no problem.
But if I add rights to the added entry, the program quits on the call to getProxyAccessListRequest reporting "Abnormal program termination".
Remove the rights and it works again.

Here is the SOAP response with no rights:

<SOAP-ENV:Envelope
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Header/>
<SOAP-ENV:Body>
<getProxyAccessListResponse
xmlns:gwt="http://schemas.novell.com/2005/01/GroupWise/types"
xmlns="http://schemas.novell.com/2005/01/GroupWise/methods">
<accessRights>
<gwt:entry>
<gwt:displayName>
<All User Access>
</gwt:displayName>
<gwt:uuid>
<All User Access>
</gwt:uuid>
<gwt:id>
<All User Access>@60
</gwt:id>
</gwt:entry>
<gwt:entry>
<gwt:displayName>
Camilla Gibson
</gwt:displayName>
<gwt:email>
Camilla.Gibson@windermere.jrbsoftware.com
</gwt:email>
<gwt:uuid>
4E06B020-05E9-0000-996A-726262333862
</gwt:uuid>
<gwt:id>
4E06B020-05E9-0000-996A-726262333862@60
</gwt:id>
</gwt:entry>
</accessRights>
<status>
<gwt:code>
0
</gwt:code>
</status>
</getProxyAccessListResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>


Here is the SOAP response with read access granted to mail.


<SOAP-ENV:Envelope
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Header/>
<SOAP-ENV:Body>
<getProxyAccessListResponse
xmlns:gwt="http://schemas.novell.com/2005/01/GroupWise/types"
xmlns="http://schemas.novell.com/2005/01/GroupWise/methods">
<accessRights>
<gwt:entry>
<gwt:displayName>
<All User Access>
</gwt:displayName>
<gwt:uuid>
<All User Access>
</gwt:uuid>
<gwt:id>
<All User Access>@60
</gwt:id>
</gwt:entry>
<gwt:entry>
<gwt:displayName>
Camilla Gibson
</gwt:displayName>
<gwt:email>
Camilla.JRBpo2.JRBDom@windermere.jrbsoftware.com
</gwt:email>
<gwt:uuid>
4E06B020-05E9-0000-996A-726262333862
</gwt:uuid>
<gwt:id>
4E06B020-05E9-0000-996A-726262333862@60
</gwt:id>
<gwt:mail>
<gwt:read>
1
</gwt:read>
</gwt:mail>
</gwt:entry>
</accessRights>
<status>
<gwt:code>
0
</gwt:code>
</status>
</getProxyAccessListResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

There are only two differences: One is the inclusion (as expected) of

<gwt:mail>
<gwt:read>
1
</gwt:read>
</gwt:mail>

But the form of the value for <gwt:email> has changed from

Camilla.Gibson@windermere.jrbsoftware.com

to

Camilla.JRBpo2.JRBDom@windermere.jrbsoftware.com

which seems a little odd.

I'm wondering if the groupwise.wsdl I used to create groupwise.cpp/groupwise.h needs updating. I used the GW1201 version which was the most recent in
novell-gwsoap-devel-2013.01.15.zip, which I believe to be the most recent SOAP development kit. Is there a newer version for 2014?

Thanks in advance, John

PS I'm also curious why the ids have @60 appended. Google has not provided an explanation.
Labels (1)
Tags (2)
0 Likes
6 Replies
Absent Member.
Absent Member.

I'm not sure what you mean by "Abnormal program termination".
I assume that is your program, right?

For the most part, you control what schema data is returned by specifying
the value in the <version> element when logging in.
The values are:
1 (or no value) - first version of the schema
1.01 - 7.0.2
1.02 - 8.0.0
1.03 - 8.0.1
1.04 - 8.0.2
1.05 - 12.0.0
1.06 - 14.0.0
1.07 - 14.2.0
1.08 - 14.2.1

It matters which version number you use and which version of the schema you
compile into C code. There are some cases when the compiled code will not be
expecting elements. There have been some cases where the structure of the
elements changed.

You can continue to use a certain version of the schema (if you don't want
to update you schema). For example, you could pass version "1.05" in the
login request even when talking to a 14.2.0 POA. If you don't need the need
elements, you can use an older version of the schema.

If you try to use a newer version on a POA that doesn't support it, the POA
will revert to version 1. For example, if you try to pass "1.07" on a 14.0.0
POA, the POA will revert to version 1.

The proxy access code converts users a full email address to uniquely
identify a person. (That is the value returned.) The format is userid '.'
post office '.' domain @ internet domain.
It is possible to have two people in the system with the same email address.
Where possible you should identify uses by the <uuid> element.

In the SOAP documentation, it describes the format of id's. The string up to
the first '@' uniquely identifies the item. The information after the '@' is
used to facilitate accessing the item. When you compare two items to see if
they are the same, you take the id string and compare up to the first '@'.
You need to pass the full id into the POA to access the item. The format of
the data after the '@' is not documented and we reserve the right to change
it.

The schema is included in the install.
It is located at
\Program Files\Novell\GroupWise Server\agents\data\wsdl
or
/opt/novell/groupwise/agents/data/wsdl

Let me know if you still have questions / or problems.

Preston


>>>


> I'm using GroupWise 2014 R2 and calling getProxyAccessListRequest as
> follows:
>
> getProxyAccessListRequest *proxyReq = new getProxyAccessListRequest;
> getProxyAccessListResponse *proxyResp = new
> getProxyAccessListResponse;
>
> soapHeaders‑>Send(sess);
> proxyResp = gwSoap‑>getProxyAccessListRequest(proxyReq);
>
> If there are no proxy entries, no problem.
> If there is only <All User Access> without rights, no problem.
> If I add an entry without rights, no problem.
> But if I add rights to the added entry, the program quits on the call to
> getProxyAccessListRequest reporting "Abnormal program termination".
> Remove the rights and it works again.
>
> Here is the SOAP response with no rights:
>
> <SOAP‑ENV:Envelope
> xmlns:xsi="http://www.w3.org/2001/XMLSchema‑instance"
> xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> xmlns:SOAP‑ENV="http://schemas.xmlsoap.org/soap/envelope/">
> <SOAP‑ENV:Header/>
> <SOAP‑ENV:Body>
> <getProxyAccessListResponse
>
> xmlns:gwt="http://schemas.novell.com/2005/01/GroupWise/types"
>
> xmlns="http://schemas.novell.com/2005/01/GroupWise/methods">
> <accessRights>
> <gwt:entry>
> <gwt:displayName>
> <All User Access>
> </gwt:displayName>
> <gwt:uuid>
> <All User Access>
> </gwt:uuid>
> <gwt:id>
> <All User Access>@60
> </gwt:id>
> </gwt:entry>
> <gwt:entry>
> <gwt:displayName>
> Camilla Gibson
> </gwt:displayName>
> <gwt:email>
> Camilla.Gibson@windermere.jrbsoftware.com
> </gwt:email>
> <gwt:uuid>
> 4E06B020‑05E9‑0000‑996A‑726262333862
> </gwt:uuid>
> <gwt:id>
> 4E06B020‑05E9‑0000‑996A‑726262333862@60
> </gwt:id>
> </gwt:entry>
> </accessRights>
> <status>
> <gwt:code>
> 0
> </gwt:code>
> </status>
> </getProxyAccessListResponse>
> </SOAP‑ENV:Body>
> </SOAP‑ENV:Envelope>
>
>
> Here is the SOAP response with read access granted to mail.
>
>
> <SOAP‑ENV:Envelope
> xmlns:xsi="http://www.w3.org/2001/XMLSchema‑instance"
> xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> xmlns:SOAP‑ENV="http://schemas.xmlsoap.org/soap/envelope/">
> <SOAP‑ENV:Header/>
> <SOAP‑ENV:Body>
> <getProxyAccessListResponse
>
> xmlns:gwt="http://schemas.novell.com/2005/01/GroupWise/types"
>
> xmlns="http://schemas.novell.com/2005/01/GroupWise/methods">
> <accessRights>
> <gwt:entry>
> <gwt:displayName>
> <All User Access>
> </gwt:displayName>
> <gwt:uuid>
> <All User Access>
> </gwt:uuid>
> <gwt:id>
> <All User Access>@60
> </gwt:id>
> </gwt:entry>
> <gwt:entry>
> <gwt:displayName>
> Camilla Gibson
> </gwt:displayName>
> <gwt:email>
>
> Camilla.JRBpo2.JRBDom@windermere.jrbsoftware.com
> </gwt:email>
> <gwt:uuid>
> 4E06B020‑05E9‑0000‑996A‑726262333862
> </gwt:uuid>
> <gwt:id>
> 4E06B020‑05E9‑0000‑996A‑726262333862@60
> </gwt:id>
> <gwt:mail>
> <gwt:read>
> 1
> </gwt:read>
> </gwt:mail>
> </gwt:entry>
> </accessRights>
> <status>
> <gwt:code>
> 0
> </gwt:code>
> </status>
> </getProxyAccessListResponse>
> </SOAP‑ENV:Body>
> </SOAP‑ENV:Envelope>
>
> There are only two differences: One is the inclusion (as expected) of
>
> <gwt:mail>
> <gwt:read>
> 1
> </gwt:read>
> </gwt:mail>
>
> But the form of the value for <gwt:email> has changed from
>
> Camilla.Gibson@windermere.jrbsoftware.com
>
> to
>
> Camilla.JRBpo2.JRBDom@windermere.jrbsoftware.com
>
> which seems a little odd.
>
> I'm wondering if the groupwise.wsdl I used to create
> groupwise.cpp/groupwise.h needs updating. I used the GW1201 version
> which was the most recent in
> novell‑gwsoap‑devel‑2013.01.15.zip, which I believe to be the most
> recent SOAP development kit. Is there a newer version for 2014?
>
> Thanks in advance, John
>
> PS I'm also curious why the ids have @60 appended. Google has not
> provided an explanation.


0 Likes
Cadet 1st Class
Cadet 1st Class

Preston

Thanks for the detailed response, there is some very useful information in there. After trying different version numbers, and using the 2014 groupwise.wsdl to no avail, some work in the debugger revealed an EPropertyConvertError exception with message "Invalid property element: 1". A google search revealed that the Embarcadero WSDL accepts only values true and false for boolean, whereas the XML spec says values true,
false, 0 and 1 are valid. GroupWise is returning "1" for enabled rights.

So, I need to raise this in the Embarcadero forums and hopefully find a work-around for C++Builder users. A quick attempt at changing the definition of AccessRights to use "short" instead of "bool" did not work.

"Abnormal program termination" was the message displayed on screen when my program abruptly quit from the getProxyAccessListRequest call.

Hans - have you encountered this in Delphi? it appears that Delphi users have access to the WSDL source and can tweak the code.

Thanks, John
0 Likes
Absent Member.
Absent Member.

Sorry, we do the opposite. We will accept true or 1 and false or 0, but we
return 0 and 1.
It would not be possible to change the code on the GroupWise side.

Preston


>>>


> Preston
>
> Thanks for the detailed response, there is some very useful information
> in there. After trying different version numbers, and using the 2014
> groupwise.wsdl to no avail, some work in the debugger revealed an
> EPropertyConvertError exception with message "Invalid property element:
> 1". A google search revealed that the Embarcadero WSDL accepts only
> values true and false for boolean, whereas the XML spec says values
> true,
> false, 0 and 1 are valid. GroupWise is returning "1" for enabled
> rights.
>
> So, I need to raise this in the Embarcadero forums and hopefully find a
> work‑around for C++Builder users. A quick attempt at changing the
> definition of AccessRights to use "short" instead of "bool" did not
> work.
>
> "Abnormal program termination" was the message displayed on screen when
> my program abruptly quit from the getProxyAccessListRequest call.
>
> Hans ‑ have you encountered this in Delphi? it appears that Delphi

users
> have access to the WSDL source and can tweak the code.
>
> Thanks, John


0 Likes
Absent Member.
Absent Member.


Hello John,



In Delphi you can access the source, but I prefer not to, because every time you import the module you have to do these modifications again. I add an extra unit with some helperclasses.



For getProxyAccessListRequest I do some special after after execute fix.

I don't know if it is a generic problem, but in the past some users have been deleted and the <uuid> or <id> is corrupted and the buildin xml parser throws an execption.

This did fix my problem: (a quick and durty solution)



const bump = ansichar($C3)+ansIchar($B0)+ansIchar($3F)+ansIchar($04)+ansichar($C3)+ansIchar($B0);
procedure TGWSoap.rioAfterExecute(const MethodName: string; SOAPResponse:TStream);
var buffer:ansistring;
begin
if MethodName<>'getProxyAccessListRequest' then exit;



SOAPResponse.Seek(0,0);
setlength(buffer,SOAPResponse.size);
SOAPResponse.Read(buffer[1],SOAPResponse.size);
// vervang c3 b0 3f 04 c3 b0 door een -
buffer:=ansireplacetext(buffer,bump,ansichar('-'));



SOAPResponse.Size:=0;
SOAPResponse.Write(buffer[1],length(buffer));



SOAPResponse.Seek(0,0); //
end;






I have created a class the does all the interfacing.

This is a the function I use, without tweaking the generated wsdl unit.

There are some constants I have defined somewhere but you will get the picture.



function TGWsoap.getProxySettings(r2:boolean=false):TstringList;
var req : getProxyAccessListRequest;
res : getProxyAccessListResponse;
i:integer;
values:TStringList;
mode:integer;
begin
add_header;
savereturn:=true;
try
result:=TStringList.Create;
result.OwnsObjects:=true;



req:=getProxyAccessListRequest.create;
try
if r2 then req.view:='misc';
res:=gw.getProxyAccessListRequest(req);
try
for i:=0 to high(res.accessRights)
do begin
mode:=0;
values:=TStringList.Create;
result.AddObject(trim(res.accessRights.displayName),values);
if res.accessRights.appointment<>nil
then begin
if res.accessRights.appointment.read_
then mode:=mode or capp_read;
if res.accessRights.appointment.write_
then mode:=mode or capp_write;
end;
if res.accessRights.mail<>nil
then begin
if res.accessRights.mail.read_
then mode:=mode or cmail_read;
if res.accessRights.mail.write_
then mode:=mode or cmail_write;
end;
if res.accessRights.task<>nil
then begin
if res.accessRights.task.read_
then mode:=mode or ctask_read;
if res.accessRights.task.write_
then mode:=mode or ctask_write;
end;
if res.accessRights.note<>nil
then begin
if res.accessRights.note.read_
then mode:=mode or cnote_read;
if res.accessRights.note.write_
then mode:=mode or cnote_write;
end;
if res.accessRights.misc<>nil
then begin
if res.accessRights.misc.alarms
then mode:=mode or calarm;
if res.accessRights.misc.notify
then mode:=mode or cnotify;
if res.accessRights.misc.readHidden
then mode:=mode or creadhidden;
if res.accessRights.misc.setup
then mode:=mode or csetup;



if r2
then begin
if res.accessRights.misc.setupSecurity
then mode:=mode or csecure;
if res.accessRights.misc.folders
then mode:=mode or cfolders;
if res.accessRights.misc.rules
then mode:=mode or crules;
end;
end;
values.Add('rights='+inttostr(mode));
values.Add('id='+res.accessRights.id);
values.Add('email='+res.accessRights.email);
values.Add('uuid='+res.accessRights.uuid);
// hier eventueel ook nog de rest ophalen.. Dutch for maybe get the other stuff.
end;
finally
res.Free;
end;
finally
req.Free;
end;
finally
savereturn:=false; //
end;
end;



Hope this will help.

Hans




>>> johnbaird<johnbaird@no-mx.forums.microfocus.com> Donderdag 30 Juni 2016 6:16 >>>







Preston




Thanks for the detailed response, there is some very useful information

in there. After trying different version numbers, and using the 2014

groupwise.wsdl to no avail, some work in the debugger revealed an

EPropertyConvertError exception with message "Invalid property element:

1". A google search revealed that the Embarcadero WSDL accepts only

values true and false for boolean, whereas the XML spec says values

true,

false, 0 and 1 are valid. GroupWise is returning "1" for enabled

rights.




So, I need to raise this in the Embarcadero forums and hopefully find a

work-around for C++Builder users. A quick attempt at changing the

definition of AccessRights to use "short" instead of "bool" did not

work.




"Abnormal program termination" was the message displayed on screen when

my program abruptly quit from the getProxyAccessListRequest call.




Hans - have you encountered this in Delphi? it appears that Delphi users

have access to the WSDL source and can tweak the code.




Thanks, John







--

johnbaird

------------------------------------------------------------------------
johnbaird's Profile: https://forums.novell.com/member.php?userid=41963


View this thread: https://forums.novell.com/showthread.php?t=499100
0 Likes
Absent Member.
Absent Member.


Hello John,



I have tried some createProxyAccessRequest and modifyProxyAccessRequest (just to a 14.2.0 system)

Where the <All User Access> is empty or filled even for some accounts with multiple <All User Access> entries

(yes my system has lost of odd info in it).

Have no problems, if you want some more code, send me an email, don't want to put all code up here.

You probably know my email.



Hans








>>> johnbaird<johnbaird@no-mx.forums.microfocus.com> Donderdag 30 Juni 2016 6:16 >>>







Preston




Thanks for the detailed response, there is some very useful information

in there. After trying different version numbers, and using the 2014

groupwise.wsdl to no avail, some work in the debugger revealed an

EPropertyConvertError exception with message "Invalid property element:

1". A google search revealed that the Embarcadero WSDL accepts only

values true and false for boolean, whereas the XML spec says values

true,

false, 0 and 1 are valid. GroupWise is returning "1" for enabled

rights.




So, I need to raise this in the Embarcadero forums and hopefully find a

work-around for C++Builder users. A quick attempt at changing the

definition of AccessRights to use "short" instead of "bool" did not

work.




"Abnormal program termination" was the message displayed on screen when

my program abruptly quit from the getProxyAccessListRequest call.




Hans - have you encountered this in Delphi? it appears that Delphi users

have access to the WSDL source and can tweak the code.




Thanks, John







--

johnbaird

------------------------------------------------------------------------
johnbaird's Profile: https://forums.novell.com/member.php?userid=41963


View this thread: https://forums.novell.com/showthread.php?t=499100
0 Likes
Cadet 1st Class
Cadet 1st Class

Brilliant! Many thanks.

John
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.