|
Hi Gary,
I have had reasonable success with CF and Crystal,
but found the CFREPORT tag somewhere between inadequate and
unworkable.
The most robust mechanism I have found is to modify
the sample calling code that Crystal provide.
Yes - it is ASP which annoys me no end, but if you
have access to ASP then it does work.
I have noted that the name of the
ODBC connection must be the same, and is case sensitive.
Also, there was (still is???) a tag in the gallery
called something like CRWPrinttofile that would call crystal 8 with some
success.
This tag falls over and crashes crystal if it is
called concurrently. I have an older site still using it, and have put code
around the
call to prevent concurrent execution. It still
crashes on occassion.
HTH
Phil.
----- Original Message -----
Sent: Monday, April 07, 2003 11:58
AM
Subject: [cfaussie] Crystal Reports and
security - no answer - but further questions
If any of you people who are
using Crystal Reports out there on CFMX can help.....
STILL can't get CFMX to execute a CR that I have set up
in the Developer/Enterprise/Professional version of Crystal - version
8.
I am using the CFREPORT tag to
call a previously defined report with an RPT extension.
I get the following error:
| An unexpected error occurred while using the
Crystal Engine.<P>Error number 599 ocurred.
|
|
I have tried to track this error down on the Seagate
site - and the help they offer does not resolve the problem.
I have also tried to track this down on
the MM site - again - no help.
The
Seagate site says it is something to do with different ODBC connections
between when the report was created and when it was run. But all this is
being done on my development machine at the moment - and I use the same ODBC
source. Of course, even if I get this resolved locally it may still not
work in a production environment if it is relying on the "same" ODBC
connection.
Gary Menzel IT
Operations Brisbane -+- ABN AMRO Morgans Limited Level 29, 123 Eagle Street
BRISBANE QLD 4000 PH: 07 333 44 828 FX: 07 3834 0828
[EMAIL PROTECTED] wrote on
04/07/2003 11:47:39 AM:
> Hi Darren, > > What calling
mechanism are you using between CF and Crystal? > I ended up modifying
the 'evil ASP' sample crystal calls provided by > Seagate, which then
displays the report in the active-x viewer. > I am not aware that the
users can then browse to other reports. > > Also, are you
generating reports on the fly, or just giving access to > pre-canned
reports created by some previous process. > > Phil. >
> ----- Original Message ----- > From: "Darren Tracey"
<[EMAIL PROTECTED]> > To: "CFAussie Mailing List"
<[EMAIL PROTECTED]> > Sent: Monday, April 07, 2003
11:14 AM > Subject: [cfaussie] Crystal Reports and security >
> > > I'm having a problem with securing some Crystal Reports
reports on a > server from people who should have access to some, but
not all reports on a > server. > > > > Firstly, I now
have exactly 40 minutes experience with using Crystal, > either
directly, or accessing reports via a web site. > > > > We
are using the 'Report Application Server' product from Crystal, not
the > 'Crystal Enterprise' product. I've been told that the Enterprise
product > will solve these problems, but that it is priced way beyond
the acceptable > solution point. (like by a factor of 10 to 30 _times_
the acceptable pricing > point) > > > > I have 3 sets
of reports. > > They are arranged under the default reports directory
in folders like > this: > > ReportRoot > >
Level_1_reports > > Level_2_reports > >
Level_3_reports > > > > Each of these sub folders has the
set of .rpt files required for that > level of user. > > The
problem is that users with access to Level_1_reports must not be able >
to access Level_3_reports. > > Crystal has a web based tool to get
these reports that is friendly enough > to give you listings of any
reports in the directory you have pointed it to, > and also to show you
any other sub-directories in that folder. The directory > is passed in
plain text in a URL variable. (These web pages are generated by > evil
ASP pages). > > Our level_1 user can be sent via a URL to their
Level_1_reports directory, > however this user has but to change the 1
in 'Level_1_reports' to a 3 and we > now have a major breach of several
privacy laws. > > These directory names are not the actual names we
are using. However, it > would not be hard for a user of the system to
be able to guess what the > other section names are. >
> > > OK, so I thought we'd add a layer of obfuscation (never a
good security > method, I know, but its straw clutching time) and try to
hide the directory > names a bit, so I moved each of the 3 report
directories down one level and > inserted a uniquely named (UID format)
directory name between each of them > and the Report Root. > >
They are now arranged under the default reports directory in folders >
something like this: > > ReportRoot > >
765328765327863215 > > Level_1_reports > >
897676438976548732 > > Level_2_reports > >
984598327504932875 > > Level_3_reports > > > >
Crystal doesn't seem to have any way to stop the user navigating back >
towards the Report Root and it then kindly gives them a list of these
3 > large directory names, which they can click on and then breach
those > annoying privacy laws. > > > > The ReportRoot
directory is not in the webroot so operating system file > permissions
only come into play. I can't think of any way to get crystal to > run as
different users depending on who the user is anyway. > > I'd rather
not hack the ASP files, because that would mean that we would > have to
patch Crystal after it was installed to activate any security, and > if
someone ever reinstalled crystal for whatever reason, and didn't
patch, > then there is no security. > > > > Has anyone
done anything like this? > > Can anyone think of a solution? >
> Should I be looking up the fines involved in breaching the privacy
laws > and get the client to factor those fines into their business
model? > > > > Regards > > > > Darren
Tracey > > > > --- > > You are currently subscribed
to cfaussie as: [EMAIL PROTECTED] > > To unsubscribe send a
blank email to > [EMAIL PROTECTED] >
> > > MX Downunder AsiaPac DevCon - http://mxdu.com/ >
> > > > --- > You are currently subscribed to
cfaussie as: [EMAIL PROTECTED] > To unsubscribe send a blank
email to [EMAIL PROTECTED] > > MX
Downunder AsiaPac DevCon - http://mxdu.com/ **************************************************************************** If this communication is not intended for you
and you are not an authorised recipient of this email you are prohibited by law from dealing with
or relying on the email or any
file attachments. This prohibition includes reading, printing, copying, re-transmitting,
disseminating, storing or in any other way dealing or acting in reliance on the information. If
you have received this email in
error, we request you contact ABN AMRO Morgans Limited immediately by returning the email to
[EMAIL PROTECTED] and
destroy the original. We will refund any reasonable costs
associated with notifying ABN
AMRO Morgans. This email is confidential and may contain privileged client information. ABN AMRO Morgans
has taken reasonable steps to
ensure the accuracy and integrity of all its communications,
including electronic
communications, but accepts no liability for materials transmitted. Materials may also be transmitted
without the knowledge of ABN AMRO Morgans. ABN AMRO Morgans Limited its directors and employees do
not accept liability for the
results of any actions taken or not on the basis of the information in this report. ABN AMRO Morgans
Limited and its associates hold
or may hold securities in the companies/trusts mentioned herein. Any recommendation is made on the basis
of our research of the investment and may not suit the specific requirements of
clients. Assessments of
suitability to an individual's portfolio can only be made after an examination of the particular client's
investments, financial circumstances and requirements. **************************************************************************** ---
You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To
unsubscribe send a blank email to [EMAIL PROTECTED] MX
Downunder AsiaPac DevCon - http://mxdu.com/
---
You are currently subscribed to cfaussie as: [EMAIL PROTECTED]
To unsubscribe send a blank email to [EMAIL PROTECTED]
MX Downunder AsiaPac DevCon - http://mxdu.com/
|