Closed Bug 405643 Opened 17 years ago Closed 17 years ago

can't add attachments with domino web access, "Domino web access error"

Categories

(Core :: General, defect)

Product:
Core
Component:
General
Version:
1.8 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: m3rlino, Unassigned)

References

Details

(Keywords: regression)

Attachments

(1 file, 1 obsolete file)

better log / Firefox 2.0.0.9
48.41 KB, application/x-zip-compressed
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.10

After the upgrading of firefox, for me it's impossible to open the file upload window for lotus notes, it tells that there is a domino web access problem.

Reproducible: Always

Steps to Reproduce:
1.Create a new mail with web access for lotus notes emails
2.Push attachments
3.Click attachment icon
Actual Results:  
It comes a dialog window who tells "Domino Web Access Problem"

Expected Results:  
It should open the fileopendialog
Over to Firefox::General, since the update clearly applied ok.

A secondary issue, but did you use System Restore to roll back to 2.0.0.9 ? The Build Identifier string looks like 2.0.0.9 except for the very last part.
Component: Software Update → General
QA Contact: software.update → general
Version: unspecified → 2.0 Branch
Creating a new message/phone message opens up a new window as it should but attempting to move a selected e-mail address does not bring a new window up to perform this operation.

I confirm this to happen 100% of the time with Firefox 2.0.0.10 for both the Windows version as well as Linux version. Previous versions of Firefox (2.0.0.9 and under) do not cause this error). Definitely a bug - needs a champion soon!


My issue is the same. After autoupdating to version 2.0.0.10 and attempting to add an attachment using the attachment button brings up the Domino Web Access Warning. Uninstalled version 2.0.0.10 and re-installed 2.0.0.9 and everything is working fine. I agree this is definately a bug! Checked this out on 3 computers, two windows XP and one Windows Vista - same problem.
Flags: blocking1.8.1.11?
Keywords: qawanted, regression
Status: UNCONFIRMED → NEW
Ever confirmed: true
Can one of the people who can reproduce this bug use the "-mozilla1.8" builds from ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/ and try to find a single-day regression range for when this broke? Best way to do that would be to perform a binary search between 2007-10-25 2.0.0.9 builds and the most recent builds.
Need help reproducing this - a trunk regression range would be useful too.
Is there a publicly accessible domino website that reproduces this problem? If so, we could help triage when this was introduced...
Looks like there is a sort of demo (by invitation only) called Greenhouse Lotus. Says on the site that you can access Lotus inotes Domino Web Access. Here's the link: https://greenhouse.lotus.com/join/MainDocumentSelf?openForm. I don't know if it's the same as Domino Web Access that I am using. And will they let you join?? You could always ask.
I filled in the form on greenhouse.lotus.com, but no response from them yet. I bet its related to some "fishing for sales leads" project.
Do we have a talkback stack that can help us here?
File attach works for me but SEND and SEND&FILE buttons won't do anything
however I can save the note as DRAFT [under WinXP and Ubuntu 7.10], then I can
see the draft from within LotusNotes 7 application in WinXP Pro.
Summary: crash if i try to use a component with domino web access, "Domino web access error" → error if i try to use a component with domino web access, "Domino web access error"
Summary: error if i try to use a component with domino web access, "Domino web access error" → can't add attachments with domino web access, "Domino web access error"
fyi: just granted a demo account on greenhouse.lotus.com...trying to repro bug
Status: NEW → ASSIGNED
Status: ASSIGNED → NEW
Product: Firefox → Core
QA Contact: general → general
Version: 2.0 Branch → 1.8 Branch
Are there any errors in the JS console?
I can create new email, and send email just fine on greenhouse.lotus.com.

However, if I try to create email with attachment, as described in comment #0, I get: 

Error: DlL has no properties
Source File: https://greenhouse.lotus.com/iNotes/Forms8.nsf/iNotes/Proxy/?OpenDocument&Form=s_JSRead2&l=en&gz&CR&MX&TS=20071012T173546,96Z&charset=ISO-8859-1
Line: 6

...in the Error Console, and I never see a file chooser dialog box. I note the error message is slightly different then originally reported by filer. Maybe greenhouse.lotus.com is running a slightly different version?
Anyone know if domino uses any jar files (which would point towards bug 369814)? If not, it seems like this must have been caused by bug 402649, or domino simply relies on old broken behavior. bz, any thoughts?
I have an email into the domino team. I should know more tomorrow.
Depends on: 404627
To check whether domino depends on referer headers, could someone who has access to one of these servers set the "network.http.sendRefererHeader" preference to 0 in about:config in a working build and see whether it breaks?  That would at least give us a baseline...
Also, is this a problem on trunk?  If not, and if someone builds and can reproduce, does the patch in bug 404627 help?


I can reproduce the problem on trunk as well.
Ugh, I can reproduce the problem mentioned in comment 16, but *not* the problem mentioned in comment 0. In fact, nobody seems to be able to reproduce that comment on http://greenhouse.lotus.com in any version (although we do get that other one in the JS console, just seems like an unrelated issue)
(In reply to comment #15)
> Are there any errors in the JS console?
> 

Not for me.
In other words, we still have not been able to reproduce the original problem. The http://greenhouse.lotus.com demo site has a different issue -- appears to be a site bug since even Firefox 1.5 gets the same javascript error.
(In reply to comment #23)
> (In reply to comment #15)
> > Are there any errors in the JS console?
> 
> Not for me.

Can you go back to a working version (2.0.0.9) and then change the referer pref as in comment 19? This pref is checked dynamically, you can change it, test, and reset it all in the same session.
On a local Lotus Notes installation, connecting with Firefox 2.0.0.10, we clicked on New Message, then on Attachment button, and we get:

Message:	DlL has no properties
URL:	http://localhost/iNotes/Forms8.nsf/iNotes/Proxy/?OpenDocument&Form=qpread2&l=en&CR&MX&TS=20071128T025751,85Z&charset=ISO-8859-1
LineNum:	6

Call Stack:
Sorry, not yet implemented
Date:	Tue Nov 27 2007 19:46:01 GMT-0800 (Pacific Standard Time)
UserAgent:	Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.1.10) Gecko/20071115 Firefox/2.0.0.10
Canonical UserName:	CN=mozqa/O=mozqa
h_PageUnid:	1D9083D5090CE70D882573A100148E1C


When we connect to the same Lotus Notes install using Firefox 2.0.0.9, click on New Message, and then on Attachment button we get the chooser dialog box.
(In reply to comment #19)
> To check whether domino depends on referer headers, could someone who has
> access to one of these servers set the "network.http.sendRefererHeader"
> preference to 0 in about:config in a working build and see whether it breaks? 
> That would at least give us a baseline...

Changing this preference to 0 had no affect on 2.0.0.9. We could not reproduce the bug on 2.0.0.9 with or without that change.

We went into the Domino server and added a mime type for .jar files to C:/Domino/jvm/lib/content-types.properties but this had no affect on the results in comment 27. Firefox 2.0.0.9 showed no bug with or without network.http.sendRefererHeader set to 0 (default was 2). Firefox 2.0.0.10 had the bug with or without network.http.sendRefererHeader set to 0 (default was 2).
Keywords: qawanted
Testing again using Firebug...

I profiled New Message window, specifically doing the following:
  1. Open Domino
  2. Select the "New" menu
  3. Select "New Message"
  4. Start Firebug profiling
  5. Select "Attachments" which reveals the attachments div
  6. Press the "Open" graphic

In Firefox 2.0.0.9, we see that the GeckoFilePicker_open function is called in s_GeckoFilePicker.js. This file is located inside http://localhost/dwagss.jar. Domino is calling that file from with the jar.

In Firefox 2.0.0.10, the GeckoFilePicker_open function never gets called. Presumably this is because the jar file can't be accessed.

I'll let smarter minds than mine voice in, but this sounds like this is expected behavior of Firefox 2.0.0.10 post bug 369814.

Note: in doing this change, we *think* we had the mime type set to application/java-archive per comment 28, but it's hard to tell in the Domino server.
We did another experiment. In c:\domino\data\httpd.cnf, we added the following:
AddType  .jar      application/java-archive             # jar files

...at the top of this text file, restarted the notes server, and tried running same email-attachment experiment again. Failed out with the same error as before.

        Attachment #290498 -
        Attachment is obsolete: true

    
    

    
  
According to the log dwagss.jar is being correctly served as application/java-archive with the server changes made above -- why isn't that fixing it? are there more jar: URIs?
No longer depends on: 404627

    
    

    
  
John, did you try clearing the cache in Fx 2.0.0.10 before running the experiment?  The HTTP log shows us mostly getting that file from cache (at least once with the wrong type, even).

    
    

    
  
Summary of offline findings:

1) We reverted to a standard http.cnf, restarted the Domino server, removed the Firefox profile, connected to the Domino site and were not prompted for priviledges. Adding attachments to an email fails. We noted that the error in comment#0 and comment#16 are the same. Comment#0 is the title of the dialog box. Comment#16 is presented after clicking "show details".

2) We made the http.cnf change specified in comment#30, restarted the Domino server, removed the Firefox profile, connected to the Domino site with a fresh profile and when prompted for priviledges, click "Allow". If you do all these, then you can add attachments just fine. 

We verified this on various combinations of Leopard, Tiger, Vista, WinXP, FF2.0.0.9, FF2.0.0.10rc1, FF3-nightly-2007112705, FF-nightly-2007112704.

This is definitely a side effect of the bug#369814. This is not something we intend to back out. We will release note this, but its a feature, not a bug.

    
    

    
  
Summary of offline findings:

1) We reverted to a standard httpd.cnf, restarted the Domino server, removed the Firefox profile, connected to the Domino site and were not prompted for priviledges. Adding attachments to an email fails. We noted that the error in comment#0 and comment#16 are the same. Comment#0 is the title of the dialog box. Comment#16 is presented after clicking "show details".

2) We made the httpd.cnf change specified in comment#30, restarted the Domino server, removed the Firefox profile, connected to the Domino site with a fresh profile and when prompted for priviledges, click "Allow". If you do all these, then you can add attachments just fine. 

We verified this on various combinations of Leopard, Tiger, Vista, WinXP, FF2.0.0.9, FF2.0.0.10rc1, FF3-nightly-2007112705, FF-nightly-2007112704.

This is definitely a side effect of the bug#369814. This is not something we intend to back out. We will release note this, but its a feature, not a bug.
Flags: blocking1.8.1.11?
OS: Windows XP → All
Hardware: PC → All
Flags: blocking1.8.1.11?

    
    

    
  
Something got lost between comment 33 and comment 35. Editing the Domino server configs to serve .jar files as application/java-archive appeared to fix the problem. But sometimes our profiles stopped working, not sure why they're getting into a stuck state.

In a corporate environment we expect the javascript capability privileges are pre-remembered.
Flags: blocking1.8.1.11? → blocking1.8.1.11-
Keywords: relnote
OS: All → Windows XP
Hardware: All → PC

    
    

    
  
Thank you that you took care about this problem. How should i classify this bug? WONTFIX?
Greetings

    
    

    
  
(In reply to comment #38)
> Thank you that you took care about this problem. How should i classify this
> bug? WONTFIX?
> Greetings
> 

Uhhh ... Does this mean it's not going to be fixed?

    
    

    
  
As i understood it's a normal behaviour, but every domino administrator will have to change server settings, since by default they don't include that line...


    
    

    
  
(In reply to comment #40)
> As i understood it's a normal behaviour, but every domino administrator will
> have to change server settings, since by default they don't include that
> line...
> 

Then why did it work up until 2007-11-15-03 in FF and it still works in IE and other browsers? As well Daniel in Comment #37 stated that there are still issues.

    
    

    
  
(In reply to comment #40)
> As i understood it's a normal behaviour, but every domino administrator will
> have to change server settings, since by default they don't include that
> line...
> 

Then why did it work up until 2007-11-15-03 in FF and it still works in IE and other browsers? As well Daniel in Comment #37 stated that there are still issues.

    
    

    
  
> Then why did it work up until 2007-11-15-03 in FF 

Because it was relying on functionality that turned out to be insecure.  A security fix on that day restricted the functionality, but Domino uses the insecure version by default...

> still works in IE

Because it does different things in Firefox and IE.

Can we get IBM to ship an update that will fix the problem on their end instead of relying on people to fix it by hand?

    
    

    
  
(In reply to comment #43)
> Can we get IBM to ship an update that will fix the problem on their end instead
> of relying on people to fix it by hand?
> 

We're talking about updating literally thousands of servers.

I have the Domino team involved. I've pointed them to this bug.



    
    

    
  
Unfortunately, the functionality was changed in Firefox because there was a security issue so this is a permanent change to Firefox. 

See http://www.mozilla.org/security/announce/2007/mfsa2007-37.html. 

    
    

    
  
> We're talking about updating literally thousands of servers.

Yes, I realize.  It's still easier to get that to happen if a vendor ships a bugfix than if thousands of people have to make manual configuration changes, or so it seems to me.

    
    

    
  
correcting platform, OS.
OS: Windows XP → All
Hardware: PC → All

    
    

    
  
Just as a final confirmation that this bug was indeed caused by the patch for bug 369814, John and Tomcat set up the test Domino server in the "broken" default config (JAR files sent with application/octet-stream), and I verified that a current branch build *without* dcamp's fix for bug 369814 does not show the bug.
Blocks: jarxss

    
    

    
  
(In reply to comment #48)
> Just as a final confirmation that this bug was indeed caused by the patch for
> bug 369814, John and Tomcat set up the test Domino server in the "broken"
> default config (JAR files sent with application/octet-stream), and I verified
> that a current branch build *without* dcamp's fix for bug 369814 does not show
> the bug.
> 

Sorted all in a matter of one day. That's actually pretty sweet when you think about it.

    
    

    
  
(In reply to comment #49)
> Sorted all in a matter of one day. That's actually pretty sweet when you think
> about it.

Very sweet. Probably saved a lot of support calls and debugging.

We (IBM) are going to put together a support posting for this and will integrate the change to httpd.cnf in future releases of Domino.

We really appreciate the effort in tracking this one down.

I'm marking WONTFIX since obviously the Firefox stuff won't be backed.

Thanks for all the help!
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WONTFIX

    
    

    
  
(In reply to comment #50)
> (In reply to comment #49)
> We (IBM) are going to put together a support posting for this and will
> integrate the change to httpd.cnf in future releases of Domino.
Cool. If the support posting will be public, can you update this bug with the URL? It would be good to link to it in our release notes/ FAQs.

> I'm marking WONTFIX since obviously the Firefox stuff won't be backed.
Sounds good.

    
    

    
  
Comment from the DWA team:

Any possibility of actually checking for a .jar extension and treating that as a jar in the browser? Or would there still be a security issue?

    
    

    
  
The Content-Type requires a proactive step by a web server admin to say they know it's active content, a much safer stance. Trusting the extension over the Content-Type header is something IE has been much criticized for in the past and has contributed to vulnerabilities on some web sites.

Unfortunately Firefox themes use a .jar extension. An unsuspecting site might innocently host themes not realizing that would open them up to an XSS vector if we relied only on the extension.
 

    
    

    
  
I'm not following how forcing an admin to adjusting their server configuration file which maps specific file extensions to particular MIME types to add an explicit listing for .jar to application/java-archive is much safer.

All existing and future files placed within the webserver with a .jar extension are now going to be served up with the application/java-archive MIME type.  I don't follow how this makes Firefox any more secure.

You should adjust the fix to treat any urls with a .jar extension as a "application/java-archive" MIME type to not break the various apps running today on servers without this mapping specified, and annoying millions of users and administrators.  You can force everyone to add this specific MIME mapping to thousands of servers, but you are fooling yourself if you think this is helping with security.

Are you suggesting that sites disallow users to upload any .jar files?...since once servers have been updated to do this mapping of .jar to the proper MIME type, the same issues arise.

    
    

    
  
> Are you suggesting that sites disallow users to upload any .jar files?

Yes, and any site that cares about security already does this, because they can be used by Java to attack the site...


    
    

    
  
Hey cool weblog, simply questioning what anti-spam software program you utilize for comments because i get heaps on my blog. Anyway, in my language, there are not much good source like this.
http://www.vertexonlinebackup.com/cms/features/web-access.html

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: