Issues with getDownloadUrl
Hi,
We very often use the function a.getDownloadUrl(....) and its been working great.
But, we just implemented one our our solutions for a customer and it does not work as intended.
We recive the correct URL.
https://online2.superoffice.com/CustXXXXX/CS/scripts/customer.fcgi/getAttachment/1111111-TheKey-0/File.docx
But, once we run the link, we just hit the customer portal and the message: You do not have access to this page.
If i generate an internal url (rms.fcgi), it works just fine, but thats not an option in this case.
We have noted that SOME older files works, but not new onces.
And it doesnt matter if the attachment is uploaded through service GUI, created by base64, and of course, the request/message is external and so forth.
This is an old old customer with a previous onsite installation.
Exactly the same code works flawless for 10+ other online customers.
Any ideas?
Regards
Pär Pettersson
All Replies (10)
I just hit the same issue at a OnSite 10.1.6 installation, we generate a download link for the attachemt with the parameter external true, but the download link returns a 401.
Sample code:
Integer attachmentId = 228548;
Attachment attachment;
if (attachment.load(attachmentId) == true)
{
// url to download zip files externally, /scripts//customer.fcgi/ etc
String downloadUrl = attachment.getDownloadUrl(true, true);
// add service base external url in front
downloadUrl = getExternalProgram(0) + downloadUrl;
printLine(downloadUrl);
}
Result url: https://crm.domain.com/scripts/customer.fcgi/getAttachment/228548-9uy6G6egBGL6w6o4nDEowiuUl9XNGEC8XlS1Ye9tbPj54yo3WhWfQB9XYopUw4P8-1/attachmentfilename.zip
But the url returns an 401 unauthorized when opened.
Is this by design? not possible anymore to generate an external access link for a attachment? (not for use within customer center, so no custSessionKey)
I did exactly the same earlier today, but in online, and that worked just fine.
Might be some really stupied questions, but, might we worth it.
1. Are the url acctual .com/scripts, you dont have an service application .com/service/scripts?
We have seen this when the crmx.config och crmx.registry is incorrectly setup when using getExternalProgram(0)
2. Do you have windows auth on the site?
We have seen at one customer that they somehow manage to "force disable" the windows auth promt whenever the user wouldnt be automaticaly logged in, ending up in a hard 401 error page
Just my 2 cents, will give it a closer though tonight
What happens if you test this with a picture, such as .jpg of .png ? Perhaps a zip-file is not supported.
I have just tested in Online and have a working link which looks like this:
https://online3.superoffice.com/CustXXXXX/CS/scripts/customer.fcgi/getAttachment/361-6DBMA66JeMX8XfBrPTIPl9xK3BRRpOAtxYytuJPkhosePTxh9t59r6nblabla-0/example.png
Tried a jpg attachment using the above code but that gives the same issue in my SOD tenant.
Works: (if logged in):
https://sod2.superoffice.com/Cust11255/CS/scripts/rms.fcgi/getAttachment/471-623nZCx3z8BsJxCrT5yTkaQFG4EJ5Ptp72lRShu2gw8gRSxsoWCPYEuuD4lxIMLi-1/Time%20for%20change.jpg
Does not work:
https://sod2.superoffice.com/Cust11255/CS/scripts/customer.fcgi/getAttachment/471-623nZCx3z8BsJxCrT5yTkaQFG4EJ5Ptp72lRShu2gw8gRSxsoWCPYEuuD4lxIMLi-1/Time%20for%20change.jpg
Hi David,
I have done the same test in SOD:
1) Create a request
2) Add a message with an attachment in the request (internal comment + attachment)
3) Find the attachment ID >> use attachment in your script
4) Evaluate the URL
Result: unable to open the link.
Other test (in SOD):
1) Go to Service >> Knowledge Base >> External documents
2) Upload a new document
3) In the final overview > right click on the arrow-button, get the download-URL
4) Paste URL in browser > replace rms.fcgi with customer.fcgi
Result: works - I am able to open the link.
I have evaluated if there are any differences in the attachment properties - I am unable to find any differences.
Please note though that "external documents" are managed via the following database reference: external_document. I suppose this is "where the magic happens"
Conclusion: I suppose this only works when the document are uploaded via the "External documents" folder.
Please also have a look at this community post:
and:
There, the conclusion is that regular attachments (not via "external documents") require a customer session in the URL in order to access them.
Time to create a third parameter for the getDownloadUrl method, "reallyExternal". 😅
I dont agree, we have this fully functional in production (built today)
In the following example, we download a document from S&M to attachment, and then in the frontend we just add the url + data["url"] and open it up in a new tab, and it downloads just fine.
...............
Attachment a;
a.setValue("name",docEntity.GetName());
Integer id = a.save();
NSStream docStream = docAgent.GetDocumentStreamFromEntity(docEntity);
a.saveBase64(encodeBase64(docStream.GetStream()));
Map data;
data.insert("url", a.getDownloadUrl(true,true));
print(data.toJson());
}
%>
%EJSCRIPT_END%
You can try and download it from here:
https://online2.superoffice.com/Cust25027/CS/scripts/customer.fcgi/getAttachment/126-yA76S5p8ow64Hb9kbtRnehQl6x3ArUCTi7jFgQqeJcaASntBppPEdM5zlY6aREbA-1/just-a-simple-test.docx
Two other solutions we also built when SuperOffice is causing these kinds of problems.
1. simply to a restcall and fetch the base64 (together with the sessionkey so you can validate and all that), then let javascript handle the base64 response, build the file and just save it
2. use the printBin function (there are some examples here on community if you search for printbin), although, that seems to be very very flawed, because some documents works, some does not (Thats why we had to att the document as an attachment in my example above)
## Conclusion.
The error occours if the attachment is connected to eighter a Ticket or a message.
For example: Create an attachment, save it to an extra table, but, also add the attachment id to a message, or an extrafield on a ticket.
Solution: Simply create 2 attachments