Authenticated Multi File Uploads – A possible solution

Jake has been work hard on building some excellent Flex components which play nice with Domino.

One issue he has hit is with a bug in the Flash Player which means for non IE browsers session authentication is not sent with the fileupload HTTP Post.  This means currently only anonymous individuals can upload attachments on non IE browsers.  This of course could be a real problem for applications which require users to sign in – is there any that don’t?

To get around this I have been brainstorming an idea which hopefully gets around this problem.

My original suggestion was just to allow the post to go to a design element which allows Write Public access and have an agent do the actual attaching – a proxy service.  The problem is this HTTP Post could then be executed by anyone who could see the HTTP traffic – though the actual agent would expect a valid UNID and discard anything else, this in turn with the fact that this would only work for documents which an originally authenticated user could see (to get the UNID) mitigates the risk quite allot.


The following flowchart describes a process which should mitigate even that issue. 

It basically shows that the initial request to Domino is to a restricted agent to create a stub document which in turn returns the UNID of this stub document.  This stub document UNID is then used to post the attachment via the public access agent – this agent will then look for the stub document to complete the request.   No stub document then no attachment.

As a new stub document is created for each request (and then discarded) it shouldn’t be possible for anonymous user to reuse the HTTP Post.

Discussion — 12 Responses

  • Jake Howlett January 27, 2010 on 2:37 pm

    Hadn’t thought of that as a solution. Good thinking! It’s the least nasty of the solutions I’ve thought of or had suggested so far!

  • Jerry Carter January 27, 2010 on 7:36 pm

    Good job Mark. It’s like a code tear sheet… one code per day and then it’s torn off and disposed of.

    What’s interesting is that this provides a form of caller verification that is useful in a number of contexts – just think of any webservice you’d like to publish but don’t want the automated process to have to authenticate to. We had to do something similar with internal webservices for a client without opening the potential for bogus transactions – money was on the line if our solution failed – and it passed the careful scrutiny of the security group to do it just as you have described.

  • Mark Myers January 28, 2010 on 12:01 am

    nice solution, clearly explained

  • admin January 28, 2010 on 8:01 am

    Thanks guys – Jerry its nice to know the theory has been sanity checked!!

  • Chris C February 12, 2010 on 3:45 am

    Has anyone given this a try? I would love to find a working demo of this.

  • Matthias Wille August 3, 2010 on 10:51 pm

    Not sure what this issue is that you have with Flash and non IE browser with regards to the session authentication when doing a file upload via HTTP post.

    I’m using the method described here…

    to authenticate a Flex/Flash session with a Domino server and it seems to be working fine with all browsers. Having said this I have not been experimenting with file uploads via HTTP post. So I’m not sure if this authentication method will help you.

    An alternative to an HTTP post could be web services. Unfortunately a file upload via a Domino web service causes the HTTP server to go to its knees if the file size goes beyond 1MB (server CPU goes to 100% for a prolonged period). This seems to be a known issue which IBM does not intent to fix. If anyone cares to try, there is a file upload web service examples available on We have tried using the provided solution to post documents from LifeCycle to Domino and gave up on.

    Currently I’m developing a generic file upload servlet. I have already done this in the past for a product called Integra for Notes and it worked quite well.

  • admin Matthias Wille August 4, 2010 on 8:19 am

    Thanks for the info Matthias – I assume your application would be contained within a SSL as well which would help to mitigate the issue.

  • Matthias Wille August 17, 2010 on 12:00 pm

    To be honest I haven’t given SSL yet much attention. Need to get this working in the first place. But once I’m there I will certainly consider SSL as well.

  • Mark Leusink August 18, 2010 on 7:21 am

    I’ve created a demo application for multiple-file uploads to a Domino server that uses a Flash based uploader (SWFUpload) and an authentication solution inspired by this article. It doesn’t use Flex, but a combination of HTML, Javascript, CSS and the “hidden” Flash component. The DominoDisableFileUploadChecks isn’t required and it does a basic post to a NotesDocument without using a servlet.

    I’m currently working on an accompanying article describing what it does and it’s features and will post it when done.

    Regarding the SSL question: although not tested it should work with SSL, but only with trusted certificates, not self-signed certificates. This is probably the same for a Flex based solution.

  • admin Mark Leusink August 18, 2010 on 8:11 am

    That sounds great Mark.

    I would be really interested in seeing that working – particularly interested why you do not need the DominoDisableUploadChecks. Are you performing the upload within the Notes database or from another domain?

  • Mark Leusink August 18, 2010 on 9:58 am


    The upload is done in the Notes database.

    The DominoDisableUploadChecks isn’t needed because the upload is performed in 2 steps: I first do an ?openForm request to the target form. That form contains a file upload control, so the response of the request gives me a valid name for the file data ( I then use that name when uploading the file(s). Drop me an email and I’ll send you the demo database.

  • Mark Leusink September 10, 2010 on 9:46 am

    The article about the demo application I’ve written (including a download of it) can be found at my blog at