Troubleshooting secure rest services

Official Content

Here you will find some guidelines that can be useful when you have trouble working with Rest Web services. Some cases may require troubleshooting; more specifically, here we'll focus on secure rest services (Integrated Security property is enabled). In this case, in particular, services need an Authorization header (and some other headers) to be executed.

So, this paper can be useful in the following situations:

1. You develop Secure REST Web Services in GeneXus using GeneXus Access Manager (GAM) and you're getting some errors.

2. You're having trouble with a rest web service generated by the Smart Device Generator. See Online Native Mobile applications architecture.

3. An HTTP Error is thrown; for example: Http Error 500 (Internal Error 500 The server encountered an unexpected condition that prevented it from fulfilling the request), 401 (Unauthorized 401 The parameter to this message gives a specification of authorization schemes that are acceptable. The client should retry the request with a suitable Authorization header).


It can be useful to try to consume the service from an external tool to get the real error, and to do a quick trial & error. In this document, we use the Advanced Rest Client (Chrome), one of the many tools available to test Rest services. In most cases, sniffing client-server traffic with a tool for that purpose can also help.


Consider the following example, where you get an error when tapping on an option of an SD panel that calls a server procedure. The procedure is secure (it has Integrated Security Level property = Authentication or Authorization).

Below are some steps to follow first:

  • Check the server log.
  • Check the ADO NET or JDBC log on the server.
  • Use a sniffer to check the traffic and the call to the service. It can be Tcptrace, for instance (or any other).

To redirect the call from the client to the server, to be captured by a sniffer (or a proxy), change the Services URL property to point to the port where the proxy listens.

Troubleshooting in SD using the services URL prop

Execute the tcptrace indicating the same port used in services URL property:

Tcptrace settings

All the traffic is going to be shown in the Tcptrace console.

Using a Rest client to do trial & error

When you call a secure rest service, if a valid session doesn't exist for the user, the application asks for an access token when it starts to run.

In Tcptrace you can see an example of a call to the access_token service - which returns a valid access token given the Application credentials.

Note that the HTTP POST is done to /oauth/access_token and some specific headers are added. The body needs to include the Application credentials (Client Id and Client Secret information) and the grant type. In the example, the grant type is "device" because an anonymous user is being used (Auto-Register Anonymous User Property is set to true in the main SD panel).

Tcptrace calling access_token

So, the same call made from the Rest client would be as follows. Note that we add the necessary headers and the payload (the JSON body).

RestClient Test1

RestClient Test2

After you get the access_token, you can execute an HTTP GET to any services adding the access token to the Authorization header of the request, as shown in the image below:

RestClient Test3

Note that to execute the HTTP GET you need to add some headers, which can be seen in Tcptrace when you call a server procedure from an SD application:

Tcptrace calling a rest dataprovider