Symptoms

When attempting to submit a file via the file attachment control while on an iPad in Safari we get the following error in the UI: image.jpg File not uploaded Details Details: File Not Uploaded The file could not be uploaded. The network might be down or web server is unreachable. contact your administrator.
 

Diagnoses

At first we believed this to be the known issue with isolated storage errors in our event viewer. This issue has been resolved with the smartforms rollup patch, however when we applied this patch the behavior did not change.

We then reverted the patch itself since it did not help. This event viewer error did in fact show every time we navigated to a smartform and attempted to upload a file via the file attachment control, so they were related. I navigated to this same broken form on my iPad and saw the same behavior. It was noted that this works on everything besides an iPad using safari. Our Smartforms Designer Runtime site was using basic authentication along with Windows Auth.

With this information I was able to reproduce the issue on my own VM and saw that if we changed our authentication to use Forms Auth instead of Windows Auth, we would then be able to upload a file to a file attachment control on a smartform. I also saw that we could instead utilize the chrome browser in order to get around this issue as well, instead of changing the authentication type on the site.
 

Resolution

We changed the Authentication on our K2 Designer Runtime site to use Forms Authentication and disabled Windows Authentication. After this we did an IIS reset and also cleared the browser cache for our Safari Browser on the iPad. After clearing the cache however we ran into an issue with Windows STS not correctly navigating to the proper IIS bindings for smartforms. This was because we purged out the old Auth Cookie that had been created a while back. It is unable to create the new cookie.

We found that the SSL cert being used on our smartforms site was in fact issued to the machine name (https://dlx:4444) instead of our desired DNS or Host Header name (https://k2.denallix.com). This means that our Claims tables entries always showed the machine on the identity providers and issuers, and are then invalid. After changing our cert to be issued to our DNS name instead of the machine name, we then ran through the configuration of K2 Blackpearl and smartforms to update the current bindings for the new cert and also in effect this will update our claims tables to use the proper URL for getting our cookie and having our user authorized, the end desired result. Now we navigated to our smartforms designer site and saw that we could now upload a file to our File Attachment control while using an iPad with the Safari Browser.

Logically this issue makes sense. There is no way that Safari, an Apple product is going to be compatible with an Authentication format that is made by Microsoft for Microsoft based technologies. The passing of the credentials in the form of a windows auth cookie is not going to occur on an iPad and also on a safari browser on top of that.

Specifically it does appear to be a Safari based issue though as other mobile browsers will work with Windows Auth enabled. Another workaround for this issue, if perhaps Forms Auth can not be enabled on this site we can also utilize the Chrome mobile browser or Firefox on the iPad and still have windows authentication enabled. These browsers create a cookie compatible with Windows Auth and will not cause the error on the file attachment control.