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:
|
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/
