REST API sticky sessions

We are a partner and one of our customers is using the REST API with an address m-files.langh.fi/.../items.aspx. Additionally there is the vault guid and preshared key present. For some reason the API stopped working around the end of Feb-24. I assume this is related to multi-server mode and sticky session and we need to do some correction to that. I have tried to add this parameter to the request: request.ServicePoint.Expect100Continue = False but that did not give any help.
Authentication token is received, but the following requests returns 403. Maybe someone can help with this issue, or if this question already have been answered. I Could not find a simple solution from the forums. Please ask if you need the specific code or more information.

Parents Reply Children
  • Yes, I am trying to find out who is the consultant for us. I think for us as a partner who has implemented the API for the end customer should have a named consultant. But I now have some additional information via Fiddler. This is the raw response of the GET request:

    {
        "Status": 403,
        "URL": "/views/V103/items",
        "Method": "GET",
        "Exception": {
            "Name": "UnauthorizedAccessException",
            "Message": "Login to vault failed"
        },
        "Stack": "Error reference ID: 88e7b9a5-65e7-40d7-968e-173ae6177b11",
        "Message": "Login to vault failed",
        "IsLoggedToVault": false,
        "IsLoggedToApplication": false,
        "ExceptionName": "UnauthorizedAccessException"
    }
    Possibly this is forbidden due to blocked IP by firewall, because I'm debugging from another location (not in the production environment) ? Maybe I should request someone to add my IP for testing purposes, in order to continue. The login data should be the same as customer uses in production. Maybe there is something wrong with the credentials, or the URL itself ?
  • This looks to me like an issue with the credentials, rather than anything else.

  • Hello Graig,

    It now turned out, that our customer is currently re-routing their M-files REST API via another web service, so that is the root reason for this malfunction. We will continue studying the case after the re-routing is complete.

    Thank you Graig for your help and advice. I will return to the issue if necessary, but I think from now on we will be communicating with the new web service interface and not directly to the M-Files server.

    Br. Tarmo