Web service token validation.

[george thomidis]

We have an implementation on the web service where we do:
1)POST log in
2)POST authenticate
3) the actual method.

In the process of limiting unwanted request we have started saving the client id from the  authentication token in storage. And directly skipping to 3. If 3 fails we call the log in and  authenticate  methods again.

I am sending this because:

1) What exactly is the correct approach for catching the invalid token?
The returned code -1 is failed to login in. But what is the error code for invalid token.

2) this is redundant because of 1 and not really important. But how long does the client id typically stays active? I find no answers to both questions in the black book v6.

[Νίκος Μάλιακκας]

You are doing the right thing. Store the client ID and reuse it as long as you don't get a negative error in the results.

From what I can understand, the clientID has all the info to login to softone if needed.

In some situations an old clientID might log you to an earlier fiscal year (the one that is originally created) but for this I am not sure if it still is an issue.

From inside softone there is a time limit for the logged session in web accounts, but if you don't provide one, it will last a lot.

You also don't need steps 1 and 2 in sequence. Provide company, branch, module and refid in the first call and the clientID you get is the one to use.

https://www.softone.gr/ws/#login

* Another option (in case we know all the parameters) *

At the end of the ws page, as you can see the error codes, all negative ones are related to login issues and if you get one you have to relogin to get a new clientID.

The approach I use is a wrapper function that checks for clientID, use it for the first time and if it gets negative error code, relogin and try again.