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
  • Hi Graig,

    Yes I have checked both of the articles, and tried to add the line wr.ServicePoint.Expect100Continue = false;

    but I do not get any cookies within the authentication response. Maybe I should send the code to someone to check it out? I have no previous experience of this API, and this is the first time I look at the code and I do not even know if the url and request parameters are correct, and if we should use some other kind of approach using the API. But I assume it has been working before. We are using .NET Framework 4.8.

  • I don't think that I've specifically seem this happen, outside of the scenarios above.  Can you show where you added that code?

    If you're continuing to have problems then it may be worth reaching out to your partner or account manager to see whether they can provide some additional support via a call or similar.

  • Hi, this is the authentication code to get token

    This is the GET request to get the data

    I have tried to add the request.ServicePoint.Expect100Continue = false; line to both of them, and  also the CookieContainer object but that did not make any difference. Maybe you can better see where the problem is. Or I can contact directly to anyone of your consultants if needed.

  • Can you use a tool like Telerik Fiddler to record the raw request and responses and take a look?

    As this is a peer-to-peer forum, if you have a service contract or similar, it may be quickest to use that to speak to some of our consultants directly.

    Equally: I too will struggle to respond this week due to our global conference. 

  • 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 ?
Reply
  • 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 ?
Children