API no longer allows retreval of attachments thumbnails.

[Joshua T M]

Hi All,

We use an internal tool for the viewing of attachments from incidents logged within Hornbill. Since the most recent update we are no longer able to do so, the call now returns a broken link.

It should be able to preview/download explorer.jpg.

The Hornbill link from the AP is:

https://mdh-p01-api.hornbill.com/strumissupport/dav/cafs_raw/fs_entity/040fd5f6ad1dea60dc1d92a7b68e3fd5de783b05.data

When trying to get it through the API it returns:

The remote server returned an error: (405) Method Not Allowed.

Using the URL directly returns “Not allowed, instead use /secure-content/ endpoint” but this is no surprise since we’re not passing in any credentials on the URL.

Can you please let me know if any changes have been made to the API or any methods that have been disabled or made defunct that would affect this?

[Gerry]

Hello @Joshua T M

Thanks for your post.  There are a great deal of "under the hood" changes happening on our platform, and one of the recent changes was the depreciation of the CAFS_RAW endpoint.  We did not consider anyone outside of our own internal developers would be using these endpoints because we have never documented them and/or flagged them for public use and so in making these changes gave no consideration to that possibility. 

Unfortunately this change in API endpoints for storage is both irreversible and is likely to continue to evolve/change over time, so reverse engineering the API calls that are being made from the browser to work out how to get this content, while obviously possible, is not going to be reliable from a business continuity stand-point, my recommendation would be not to do that. 

So as I may give you guidance, perhaps you can give me some insight as to what you are needing to achieve and I can find a more supportable route for you to achieve what you need.

[Joshua T M]

Thank you for the response @Gerry,

It really has been quite difficult to use and implement your API, the documentation has been lacking at best (as you can see from my previous posts to the community) and we have been forced to find "workarounds" in almost every use. I'd suggest at least communicating these changes made as part of the "under the hood" update, regardless of whether these changes may or may not affect your end users as more often then not they do.

I've informed our Support Manager who will respond to you with our exact needs, obviously we and certainly he has dedicated a great deal of time developing tools for our internal use. Hopefully we can remedy this quickly with as little impact as possible.

[Gerry]

@Joshua T M

As a general rule we document the API's that are public, but they are very low level and I appreciate that.  However, you mentioned

"I'd suggest at least communicating these changes made as part of the "under the hood" update, regardless of whether these changes may or may not affect your end users"`

As our service continues to evolve we change much under the hood all of the time, if we communicated every change we made it would be mostly meaningless to customers, simply because the changes do not impact things we expect customers to be using.  You said that "the documentation has been lacking at best (as you can see from my previous posts to the community) and we have been forced to find "workarounds" in almost every use.", I agree that our API docs could be better, but I would still suggest that any web endpoints that are not documented and/or recommended for use should be avoided, or perhaps better stated, use at your own risk, simply because anything like that has a good chance of getting changed/evolved or otherwise depreciated, as was in the case of the cafs_raw endpoint.  

If we have sight of what you are trying to do, then we can consider those requirements and offer the best guidance/support possible, and build into our roadmap changes that might better suit/be better supported. 

Gerry

 

[Stuart Riddell]

Hi @Gerry

Our requirement is quite simple:

    We need to preview and/or download the attachments on a request from our own in-house applications & web pages.  

Currently 6 months of work have effectively been wiped out.  It is bad enough that the .NET API is 6 years out of date, so we've had to develop workarounds such as this.   

 

However,  as I've just re-confirmed, we cannot even view an attachment whilst raising a request from an email in Hornbill.  It reports: 

    Invalid content access token

Since this is Hornbill, not our application, please see that it is addressed as soon as possible. 

 

The last week's worth of Hornbill updates have caused us no end of problems and are completely intolerable.

 

Stuart

[Gerry]

@Stuart Riddell

Ok its pretty difficult to find a community solution here while just being shouted down - let me address a couple of points. 

The first one relates to undocumented/unsupported API's, its entirely unreasonable to hold us to account when you / your team have taken it upon yourself to reverse engineer the way the browser talks to our service, made use of undocumented/unofficial API/endpoints and then hold us to account when your code breaks.  I am assuming no one from Hornbill had advised you that this was supported, and so am making the assumption that this is how you have come to use the cafs_raw endpoint?

The .NET API is a community project posted on our GitHub account in the hope that for anyone who finds it useful can use it. Furthermore it is open-source and we are happy to accept community contribution.  If its actually broken, then we are always willing to go and fix it too if/when we can.   The nature of the API is such that, while the various API's we add/update over the passage of time, the API lib is just a wrapper around composing and the XML messages, so I am not sure what "6 years out of date" means.  I am not a .NET expert so I may be incorrect here, but to the best of my knowledge, the current version of the DotNetApi lib project will work with all version of .NET v4 and above?

"as I've just re-confirmed, we cannot even view an attachment whilst raising a request from an email in Hornbill" 
If this is the case, that would appear to be a defect, I will point the dev team at this point for them to have a look, but if this is urgent and needs priority attention, please log a support request with the support team. https://hornbill.com/support

Gerry


 

[Guest Ehsan]

@Stuart Riddell,

Just wanted to let you know that the "invalid access token" error will be addressed in the next Service Manager release. This is an issue when previewing attachments while raising a Request through progressive capture, although the attachments can be viewed and managed when viewing the logged Request. As a workaround, you can remove any text starting from "&download=true" onwards from the URL to preview the attachment then and there.

 

Ehsan

[Stuart Riddell]

@Gerry

Please understand my level of frustration regarding this.   I am not prone to shouting, especially in text, but this situation is beyond words.

 

We have already raised the issue with raising requests from emails with attachments last week, after it had been previously fixed.

Last week, it wasn't attaching them to the request.  Then we had an update and it worked.

Now another automated update has gone on and broken viewing them whilst going through raising the request.  I might be able to accept it in our applications but Hornbill is breaking it's own interface.

I've asked @Joshua T M to raise another request.

 

With regards to the .NET Library, the screen shot is from the GitHub link.  Most of the other API libraries have been kept up to date but not the .NET library.  This has caused even more frustration when trying ask questions in the Community forum because the replies referred to the newer libraries and the functionality didn't exist in the .NET library.  So I had to crash course Go & PHP to work out what was actually being suggested. 

09 Feb 2021 - goApiLib
10 Nov 2020 - powershellHornbillAPIModule
27 May 2020 - hornbill_apilib (Rust)
07 May 2020 - pythonApiLib
28 Feb 2017 - phpApiLib

03 Oct 2016 - dotNetApiLib

 

I've spent 4 years getting Hornbill implemented across our group and thought that we had got it working and was looking forward to expanding it's use but the last week has severely dented that hope.

 

https://github.com/hornbill?q=&type=&language=&sort=name

[Gerry]

@Stuart Riddell

I can hear your frustration, but I want to try and address each point separately, as they are two different things, otherwise we will get nowhere fast. 

I don't understand the point about the .NET library, its stable, that does not make it out of date, that just means there is (to the best of my knowledge) nothing else to do with it, thats because the XMLMC API that it serves as a wrapper for is also stable and its self has not changed in many years.  So I am not sure I understand this problem, are you saying that the .NET library is not working? or is it feature incomplete? do the other libs do something that the .NET library does not do? That is what I am seeking clarification on, just saying its not been updated since 2016 does not mean its not working?

As for the other error you are seeing, as @Ehsan pointed out above, this is a defect and has been resolved and will be rolled out very soon, in fact this really ought to be a hotfix, I am not sure why its not, I will ask.  This is entirely our fault and has been prioritised, and I can only apologise for that problem unreservedly.

Gerry

[Stuart Riddell]

Hi @Ehsan

Thanks for the update. I've tried stripping "&download=true" and the remaining text but it's still throwing the Invalid content access token message.  We'll wait for the next Service Manager update and re-check then.

 

Stuart

[Stuart Riddell]

Hi @Gerry

The problem is when the replies refer to function calls that exist in one API library but not another.

This block is valid for calls using the GO library but not the .NET library because it was added to one but not the other.  In this respect, the API libraries need to be kept up to date.

    Esp.XmlWriter doc = new Esp.XmlWriter(); 
    doc.openElement("searchFilter"); 
        doc.textElement("column", "h_container_id"); 
        doc.textElement("value", 126); 
        doc.textElement("matchType", "all"); 
    doc.closeElement("searchFilter"); 

 

 

Whilst looking for the example above, I also found the issue where Hornbill developers told the Community how to download the attachments.  It was raised by another member and made my day when it was published.  This is the method we've been using and no longer works.

 

 

Stuart

[Guest Ehsan]

@Stuart Riddell,

Regarding the "invalid access token" error when previewing an attachment in progressive capture, we have applied an automatic update to your instance. Could you please refresh your browser and try again?

Ehsan

[Stuart Riddell]

Hi @Ehsan

It's not working for Chrome but it does work for Edge & Firefox.

Just to confirm the sequence:

1. Logged out of Hornbill
2. Shutdown Chrome completely.
3. Opened Chrome
4. Logged into Hornbill
5. Tried raising a request from email.
6. Clicking on the PNG attachment during the capture sequence still throws the token message.

However, using the other browsers:

• Edge wants to download the file
• Firefox forces it as download but that's standard behaviour for Firefox.
• Internet Explorer doesn't show any attachments in the list.  I'm testing with the same email at all times.

 

There are differences between the 3 URLs.  I've redacted portions that are not relevant.

Chrome:

https://mdh-p01-api.hornbill.com/strumissupport/dav//secure-content/inline/7aeLnD- ... P0&file=image003.png&download=true&filename=image003.png

but it does work if &file=image003.png&download=true&filename=image003.png are removed from the URL.  That backs up your previous reply.

 

Edge

https://mdh-p01-api.hornbill.com/strumissupport/dav//secure-content/download/7aeLnD-_ ... P0

 

Firefox

https://mdh-p01-api.hornbill.com/strumissupport/dav//secure-content/download/eJzgKQi6o ...Zg

 

I would have expected all 3 URLs to be consistent, except if there was session data in the URL.

 

Hope that helps.

Stuart

[Guest Ehsan]

@Stuart Riddell,

There is no browser-specific procedure to handle downloading files. I believe there is a cached state in the Chrome browser on your computer, the test in Edge and Firefox indicates that the fix has been applied to your instance.

In Chrome, could you please press F12 on your keyboard, select "Empty cache and hard reload" from the refresh icon, press F12 again to close the console, refresh the page - This should hopefully remove any cache states.

Ehsan

[Stuart Riddell]

Hi @Ehsan

Empty cache and hard reload worked.

Thank you

Stuart

[BillP]

On 6/23/2021 at 2:31 PM, Stuart Riddell said:

Hi @Gerry

The problem is when the replies refer to function calls that exist in one API library but not another.

This block is valid for calls using the GO library but not the .NET library because it was added to one but not the other.  In this respect, the API libraries need to be kept up to date.

    Esp.XmlWriter doc = new Esp.XmlWriter(); 
    doc.openElement("searchFilter"); 
        doc.textElement("column", "h_container_id"); 
        doc.textElement("value", 126); 
        doc.textElement("matchType", "all"); 
    doc.closeElement("searchFilter"); 

 

 

Whilst looking for the example above, I also found the issue where Hornbill developers told the Community how to download the attachments.  It was raised by another member and made my day when it was published.  This is the method we've been using and no longer works.

 

 

Stuart

@Ehsan

@Gerry

I've just discovered through this thread that this API has been broken for a while. In my case, it has failed in a way that doesn't cause an exception, but instead brings down an error web page, rather than the document it was supposed to fetch.

No error was reported, so I'm still working out how long this has been broken and how many bad documents have been processed by our archival process. I will say - understated - that I am not pleased.

I don't see a usable fix posted in this thread.

Do you have a plan to fix the API or replace it?

Bill

 

 

[Guest Ehsan]

Hi @BillP,

Could you please let us know the name of the API that you are using and provide us with the request/payload?

Ehsan

[BillP]

On 1/29/2022 at 8:27 AM, Ehsan said:

Hi @BillP,

Could you please let us know the name of the API that you are using and provide us with the request/payload?

Ehsan

@Ehsan I've responded on the original thread and tagged you there.

[Stuart Riddell]

@Ehsan - Thank you for the excellent write-up on the thread below, it's given me enough information to get our attachments working again.

 

 

[Guest Ehsan]

@Stuart Riddell, 

Thanks, that's great to hear