Web Services changes
There are changes in support of web services in Genero 3.10.
The XMLElementNillable, XMLOptional, and XMLNillable attributes
The management of XML serialization when serializing nillable has changed. These attributes define how a NULL value is interpreted in XML.
When using the XMLOptional attribute, the behavior of the XML serialization has changed; it no longer handles XML nillable.
The new XMLNillable attribute can be used to specify that
the XML representation of a NULL value must be xsi:nil="true"
.
In order to get the same result as when using XMLOptional
in prior versions, set
both XMLOptional
and XMLNillable
.
Instead of specifying each element individually with XMLNillable
, the XMLElementNillable attribute can be used with a BDL
RECORD
defined as TYPE
or DEFINE
to specify the
XML representation for nillable in all elements in the record. This eases migration to the new
XMLNillable
behavior, because now you can get the same behavior as before defining
database records by adding the XMLElementNillable
attribute.
- A variable that was expected to serialize an
xsi:nil
value, you must set the XMLNillable attribute on that variable. - A record defined with
LIKE
for fields in a database table which may allow null values, you must set the XMLElementNillable attribute as in the example.DEFINE var RECORD ATTRIBUTE(XMLElementNillable) LIKE customer.*
- Recompile the Genero Web Service server to create a new WSDL that supports the XML nillable feature.
- Regenerate all Genero Web Service client stubs from the newly-generated WSDL to get the support of XML nillable. Regenerate client stubs using the fglwsdl tool.
Better support for Web Services API on iOS/GMI
Most of the Web Services APIs are not available on iOS mobile devices.
There are still some exceptions, related to iOS restrictions. For details see Web Services on mobile devices.
OpenID Single sign-on (SSO) protocol not supported
Support of the OpenID Single sign-on (SSO) protocol has been dropped. This service based on Genero REST is no longer delivered in the Genero Web Services package under $FGLDIR/web_utilities/services/openid.
If you have previously used OpenID
to authenticate users launching applications,
you must now use an alternate method, such as OpenID Connect. See the OpenID Connect
SSO topics in Genero Application Server User Guide.
Define server configuration based on regular expressions
Starting with GWS 3.10.09, instead of using the
ws.myident.url
FGLPROFILE entry, you can now use a regular
expression to identify several server URLs, by using the
ws.ident.regex.url
entry.
For more details, see Web Services FGLPROFILE: Server configuration.
fglwsdl option -fRPCNamespace to support namespaces in RPC parameters
Starting with GWS 3.10.09, the fglwsdl tool supports the new option
-fRPCNamespace
to produce BDL code supporting the namespace
attribute for RPC parameters.
For more details, see fglwsdl.
fglpass option -gid to allow agent authentication through a UNIX user group
Starting with GWS 3.10.10, the fglpass tool can be used with the
-gid
to allow agent authentication for all users which belong to the group of the
current user executing the fglpass command.
For more details, see fglpass, Use the password agent.
Changes to security.global.protocol in FGLPROFILE
Starting with FGLGWS 3.10.22 GWS secured communication is based on the OpenSSL 1.1 engine. This version of OpenSSL always selects the security protocol. It no longer allows you to specify a specific Transport Layer Security (TLS) or Secure Sockets Layer (SSL).
The security.global.protocol
entry in the fglprofile file
is therefore no longer supported.
security.global.protocol = "TLsv1.2"
to configure
OpenSSL to use TLSv1.2 for HTTPS for earlier versions, you may encounter the following error message
in your Web service:OpenSSL 1.1 doesn't support specific protocol anymoreIt is therefore recommended to remove the
security.global.protocol
entry from your
fglprofile file. For more information on Web service security configuration,
see HTTPS and password encryption.Changes to how GWS handles cookies
- WSHelper.WSServerCookiesType has a new member (
sameSite
) added to the record to specify how cookies are sent to other sites. Three values are possibles for sending cookies: "Strict", "Lax", or "None". The default is "Lax". IfNULL
, the default "Lax" is used. - The com.HTTPServiceRequest.setResponseCookies method taking
WSHelper.WSServerCookiesType
as parameter may raise a runtime error if thesameSite
attribute is not set correctly. For instance, you can not set it to "None" if secure is not set toTRUE
. This raises the errorSameSite None value requires Secure to be set
.
SameSite="Strict"
on the
secure cookie ensures that only the exact URL the cookie has been set with will return the cookie to
the server. If not set, the GWS sets each cookie's sameSite attribute as "Lax".To have SameSite available, you must recompile your sources with fglcomp 3.10.24 or greater.