RELOAD=1 should work. Once the configuration is reloaded the line with RELOAD=1 will be removed automatically.
Registry functions to control Webgateway from within IRIS will work *after* the Webgateway is registered on the IRIS instance. That happens during the first/initial connection/request. It works, even if Webgateway is on a different machine/system. Please note: registry functions could be disabled in the Webgateway-Configuration. (default = enabled)

Hi Ralf,
unfortunately you did not provide the policy.

It should look like this: (in Wizard, pick "Username Authentication over SSL/TLS" - leave everything else on the defaults!)

 <cfg:configuration xmlns:cfg="http://www.intersystems.com/configuration" xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702" xmlns:wsap="http://www.w3.org/2006/05/addressing/wsdl" xmlns:wsp="http://www.w3.org/ns/ws-policy" name="service">
  <cfg:service classname="[your webservice-class]">
    <wsp:Policy>
      <sp:TransportBinding>
        <wsp:Policy>
          <sp:TransportToken>
            <wsp:Policy>
              <sp:HttpsToken>
                <wsp:Policy/>
              </sp:HttpsToken>
            </wsp:Policy>
          </sp:TransportToken>
          <sp:AlgorithmSuite>
            <wsp:Policy>
              <sp:Basic128/>
            </wsp:Policy>
          </sp:AlgorithmSuite>
          <sp:Layout>
            <wsp:Policy>
              <sp:Strict/>
            </wsp:Policy>
          </sp:Layout>
          <sp:IncludeTimestamp/>
        </wsp:Policy>
      </sp:TransportBinding>
      <sp:SignedSupportingTokens>
        <wsp:Policy>
          <sp:UsernameToken sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">
            <wsp:Policy>
              <sp:WssUsernameToken11/>
            </wsp:Policy>
          </sp:UsernameToken>
        </wsp:Policy>
      </sp:SignedSupportingTokens>
      <wsap:UsingAddressing/>
    </wsp:Policy>
  </cfg:service>
</cfg:configuration>

In SOAPUI, enable WS-Addressing. Below the request-message there is a small button-line starting with [Auth] ... here you also find [WS-A] where you can find a checkbox to enable it.
Add the WS-A to the request. Right click on the request-message -> "WS-A headers"-> "Add WS-A headers".
Right click on request-message you can Add "WSS UsernameToken" and "WS-Timestamp" if you do not have configured that otherwise in general.

This works for me.

Please note: SOAP-logging (with "iosv" flags) is always a good help.

HTH,
Bernd

Currently, there is no API to request a new session cookie.

If we wished to implement this in the absence of any real security concern it would need to be scheduled by our product management and as en enhancement.

So far you have not suggested any compelling reason to do this.

Do you have an example of a valid attack against CSP?

Sorry, but I still do not see a general CSP related vulnerability problem here.

Please let us continue in WRC problem you've already opened for this same question recently.

Thanks and kind regards,
Bernd

Hi,

i would start with the xml-structure you expect and which probably/hopefully is already defined by an xml-schema.

You can import xml-schemas into IRIS to generate XML-enabled classes which extends %XML.Adaptor.

https://docs.intersystems.com/irislatest/csp/docbook/Doc.View.cls?KEY=GX...

If you do not have a xml-schema, you need to create it or your xml-enabled classes manually. (extending %XML.Adaptor)

https://docs.intersystems.com/irislatest/csp/docbook/Doc.View.cls?KEY=GX...

If you have that ready, let your XML-enabled classes also extend %JSON.Adaptor.

https://docs.intersystems.com/irislatest/csp/docbook/Doc.View.cls?KEY=GJ...

Use %JSON.Adaptor to import the JSON data (i think DynamicObject is also supported here directly)
into your XML enabled class with the help of %JSONImport() method.

Then use XMLExport..() method (inherited from %XML.Adaptor) to export as XML data.

I have not tried this so far but i think it should work :)

HTH,
Bernd

Hi,
you can test your Node environment within a simple windows command window (CMD.exe):

C:\>node -v
v0.10.26

C:\>node
> x=require('cache.node')
{ Cache: [Function: Cache] }
> y = new x.Cache
{}
> y.version()
'Node.js Adaptor for Cache: Version: 1.0.63 (CM)'
>

Do you have renamed cache0100.node into cache.node an copied it into location specified in environment variable NODE_PATH ? e.g. NODE_PATH=C:\Program Files\nodejs
 

If not, you need to specify path to cache.node within require(), e.g. x=require('c:/mypath/tocachenode/cache')

HTH,
Bernd

Hi,

>I don't understand why its not working in the NodeJs v0.10
What error do you get? Why using such outdated/ancient NodeJS versions?

>I need to get file from Cache Database. File stored as a FileBinaryStream in DB.  

You need to provide much more details in order for us able to help you.

See docs/class-reference here which might be helping you:

https://docs.intersystems.com/irislatest/csp/documatic/%25CSP.Documatic....

Hi,
i would start with a SOAP-LOG ("ios") to see what is sent out and what SoapAction is used from within Caché soap client.
see SOAP Logging docs here.

Use/install 3rd party tool "soapUI" (there is a free version), import WSDL and try to sent request from here. See if you can make it working and chekc http-log in soapUI to see what soapUI is exactly sending out to the service.

Some WebServices requires SOAPAction http-header to be quoted. To achieve this you need to use SOAPACTIONQUOTED param in your WebClient class, e.g.

Parameter SOAPACTIONQUOTED = 1;

HTH,
Bernd

yes, internal private apache webserver (PWS), the embedded one coming with the IRIS installation is still 32-bit on windows x64.

"CSPGateway-2018.1.1.643.0-win_x64"  kit should contain 64-bit CSPGateway binarys/dlls.

You can check bitness/architecture of your apache with the command: >httpd -V

Bitness of apache and CSPGateway binarys *must* match!


There is an alternative to dumpbin in order to check bitness of CSPGateway binarys/dlls which IMHO is easier:

Open executable or dll in editor (notepad, notepad++), check the first printable characters *after* the first occurrence of "PE".

This part is most likely to be surrounded by at least some whitespace (could be a lot of it), so it can be easily done visually.

x86:

PE  L

x64:

PE  d†


HTH,
Bernd

To let *all* (and custom) CGI-Variables coming through, you probably need to set the extra environment variables in the CSP Gateway configuration.

You can set/specify via the "Extra CGI Environment Variables" Setting in the "Application Access" section in CSP Gateway Management.

If you enter a * here, *all* CGI-Variables will be sent/tranmitted and provided to Caché-Server-Side in the %request.CgiEnvs multidimensional property.

HTH,

Bernd

just to clarify:

Caché cube unfortunately does not support opening web-ressources by https directly so far. (currently only http fix)

Special version of ServerManager.exe does not help to solve this issue. It's for the "old" way of doing ssl/tls client configurations, which is not recommended for recent versions of Caché anymore.

See here Katherine's great article on the new way of configuring client application for ssl/tls :

https://community.intersystems.com/post/configuring-cach%C3%A9-client-ap...

A workaround to solve this issue with the Cube is to setup http to https redirection on the webserver level as already mentioned here by Eduard as well.

Regards,
Bernd

Hi,
underscore in method names are *not* supported and possible, I am afraid.

Besides the SoapAction already mentioned by Eduard you can try if adjusting the SoapMessageName and SoapRequestMessage keywords
at the method level in your WebService are helping to get what you want.

Here is an example:

Method AddInteger(Arg1 As %Integer = 0, Arg2 As %Integer = 0) As %Integer [ SoapAction = Add_Integer, SoapMessageName = Add_Integer_Response, SoapRequestMessage = Add_Integer, WebMethod ]
{
  Quit Arg1 + Arg2
}

HTH,

Bernd

if i remember correctly you do not need to create a custom tag in order to use your customer version of the lookup-class. You can use the default CSP:search tag and provide your modified custom lookup-class by the "searchpage" attribute.

<csp:Search name="FindPerson"
    searchpage="%ZCSP.PageLookup.cls?SEARCH&..."
    onselect="onFindCustomer"
    classname="Sample.Person"
    ...

Hi Soufiane,
as you can see in the GetAccessTokenFromRequest() method, the access token is taken from the http authorization bearer header or from the encoded entity body's access_token parameter.  As described in RFC6750, see here: https://tools.ietf.org/html/rfc6750

Your client need to send that way. Not within the url as a name/value param.

On resource server side you then need to continue with this, see section "Code Requirements" here: http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=GOAUTH_resource

Be also aware on the prerequisites and code requirements also.

HTH,
Bernd