hmmm. Good question. Yes, I suppose they could do that. Depending on how you
set up your Crystal Report, however, you probably could make it more
difficult for them to 'guess' what fields the report is expecting. For
example, this is what my final CF page has in the source code:
<FORM NAME="continue" ACTION="http://our.report.server.com/callreport.asp";
METHOD=POST onSubmit="return _CF_checkcontinue(this)">
<input type="hidden" name="reportname" value="whatever.rpt">
<input type="hidden" name="DSN" value="yourDSN">
<input type="hidden" name="DB_SID" value="yourdbschema">
<input type="hidden" name="param1" value="firstReportPrompt">
<input type="hidden" name="param2" value="1001">
<input type="hidden" name="param3" value="0902">
<input type="hidden" name="param4" value="1">
<input type="hidden" name="param5" value="1">
<input type="hidden" name="param6" value="1">
<input type="hidden" name="param7" value="">
<input type="hidden" name="param8" value="">
<input type="hidden" name="param9" value="ALL">
<input type="hidden" name="param10" value="ALL">
Since the prompt values are being passed from a template, the report will
not prompt the user for any of the needed values when the report displays in
the browser. So, even though they may see in the source code that param2 is
1001, they may not figure out that the report is requesting (in MMYY
format), the start of the fiscal year for the year that the user chose from
the form dropdown list (in this case, 2001). Likewise, there is logic in my
CF page to determine the end of the fiscal year, based on their choice
(2001) from the previous page. See what I mean? Likewise, for param9/10,
they would have no idea what "ALL" indicates, nor would they be able to
guess what the other possible values would be.
In our case, however, we are granting access to any employee to run any
report (hey, I don't call the shots--that's how the group asked me to build
it :), so we aren't too concerned with people taking the time to do
something like that.
The only reason that we are asking for an NT id and password is just so that
we can validate that it is, in fact, a valid employee logging on. We may
change this somewhere down the line and actually restrict access to certain
reports, I don't know. Our whole concern with not exposing the db id/pw was
because we didn't want people to be able to bypass reports and gain access
to the actual Oracle db.
If we DO end up restricting access based on groups somewhere down the road,
I will be sure to post an update! :)
Good luck!
----Original Message Follows----
From: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: CF-Talk <[EMAIL PROTECTED]>
Subject: RE: Report Solution (long)--My shared experience
Date: Fri, 18 May 2001 09:01:21 -0400
I haven't done anything like this but may have to soon. Question: is there
anything stopping a user from creating an html page on their desktop with a
form that posts to the report server ASP page, just like your "action" page
does? If not, it appears that anyone could run any report if they can
figure out what to put in the form fields. Or is there a step I missed?
-----Original Message-----
From: Terri Stocke [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 18, 2001 8:49 AM
To: CF-Talk
Subject: Report Solution (long)--My shared experience
Okay, all. I just spent 4 days tearing my hair out trying to figure out how
to pass CF variables to a Crystal Report(8) (while hiding the db userid and
password). I searched the archives and the Allaire site and noticed that
many other people have been gnashing their teeth over the same topic, so I
thought I would share our solution.
It's not pretty, and I'm not looking forward to supporting it, but it will
......
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
