CodeStore.net comments on "Another Happy Customer"

Reply from Jake

Jake — Mon, 31 Jan 2005 07:38:00 +0100

But there's no more danger of the Excel user's password being sniffed than that of the *real* user.

Reply from Dave Meehan

Dave Meehan — Mon, 31 Jan 2005 07:21:00 +0100

It's not that you've created another login that's the issue, but that you've provided access to secure data through an insecure mechanism. If your worried about password sniffing, what's to stop someone sniffing the password from the URL and then accessing that data when they like. And does that login allow access to other data that you weren't planning on. Or could an admin inadvertantly give that user greater rights than you planned because they don't understand the implications. Anything that circumvents the normal security model seems to me like asking for trouble.

Reply from Jake

Jake — Sat, 29 Jan 2005 04:44:00 +0100

Dave. It's not normally something I'd suggest, but, the more I think about it, the less I can see wrong with it.

The "Excel Reader" user is just a Reader with no create rights. Presumably the user who opens Excel already has at least the level of access and then some. What's the danger? That the user uses these credentials to login with? Why would they? The user is blissfully unaware that a different user's details has been used anyway. I really can't see the problem with it.

Reply from Dave Meehan

Dave Meehan — Sat, 29 Jan 2005 02:29:00 +0100

That solution concerns me. What else can the Excel user access from the database? Just the view, or other elements as well? Surely if the database is not open for anonymous access, that means that data contained therein is meant to be private. Snooped or not, this seems like a huge risk to take with the customer data.

Would some form of DHTML/Javascript solution work better? ie. get the data into the browser (embed the view to produce js statements or a data island), and then launch Excel from there, passing the data over. That way, your seperating Excels use of the data from the server.

Reply from Brendon Upson

Brendon Upson — Fri, 28 Jan 2005 22:58:00 +0100

I have had a lot of success with customers using the Jakarta POI libraries. This enables you to create the entire Excel file on the server then stream it to the browser.

{Link}

This also allows you to read Excel files to import the contents into a database.

Hope this helps,

Brendon.

Reply from Jake

Jake — Fri, 28 Jan 2005 13:09:00 +0100

It's under the Contact link on the "navigator" panel.

Jim? Jim Bobble?

Reply from julia

julia — Fri, 28 Jan 2005 13:04:00 +0100

Hi!

I've been searching your website for a contact email...I'm just not that smart. :) Do you have a contact email for Jim? Can you email me with it or have hi email me? Thanks so much!

Reply from Jake

Jake — Fri, 28 Jan 2005 03:01:00 +0100

Henk. You had me worried for a second there. Thinking about it now I knew about this change in IE. In fact it's on my machine. My IE is about as up-to-date as you can get. Why does it work then? Well, because Excel is reading the URL and it ain't IE. Not even an embedded IE if I'm right, it's just a URL fetch.

So, yes, it does work. Phew. I can cancel the call to Amazon returns dept now ;-)

Steve. That is what Kathy is/was doing after she'd given up on this method. Agents can do it and hers worked perfectly. However, like me, I suspect she'd rather do without an agent where a view will do. Wouldn't we all?

Reply from Steve Cannon

Steve Cannon — Thu, 27 Jan 2005 19:56:00 +0100

Why not call an agent that can be run anonymously. Set the agent to run with the rights of someone trusted, rather than the person invoking the agent. Your agent could then do print statements like

print ||

print |

etc, etc. If you simply want to iterate over the docs in a view, it's a fairly simple loop for the TD tags. Also, I think there's a 1000 line limit on iqy files which you avoid with the agent.

If you store the url to the agent in excel, like an iqy file, the spreadsheet will update itself whenever you open it.

Reply from Curt Carlson

Curt Carlson — Thu, 27 Jan 2005 19:07:00 +0100

I would advise against it but you can use this syntax if you are using session based authentication. Even with patched IE versions

http:///names.nsf?login&username=&password=redirectto=

Reply from Henk

Henk — Thu, 27 Jan 2005 18:48:00 +0100

Well, Kathy won't be such a happy customer anymore when she finds out that your solution doesn't work in correctly patched versions of Internet Explorer.

SUMMARY

A security update is available that removes support for handling user names and passwords in HTTP and HTTP with Secure Sockets Layer (SSL) or HTTPS URLs in Microsoft Internet Explorer. The following URL syntax is no longer supported in Internet Explorer or in Windows Explorer after you install the MS04-004 Cumulative Security Update for Internet Explorer (832894): http(s)://username:password@server/resource.ext

The link below points to the Knowledge Base article:

{Link}

This patch dates back to april last year and I would have thought that every web developer knew about this by now because of the great impact it had.

Do I get a book now? Sorry Jake, just kidding...