Connection profile details saved in rptdesign file

[alex-axiobit]

When using a connection profile the report designer keeps saving these details in the .rptdesign file.
I believe it sould not save them in the .rptdesign as long they are specified in the connection profile file.

report.rptdesign

<property name="odaDriverClass">org.postgresql.Driver</property>
<property name="odaURL">jdbc:postgresql://localhost:5432/my-postgres-database</property>
<property name="odaUser">user</property>

config.xml

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<DataTools.ServerProfiles version="1.0">
    <profile autoconnect="No" desc="" id="d04355a1-7c01-11ef-878c-9abc7ec407b6" name="claim2me_db_profile" providerID="org.eclipse.birt.report.data.oda.jdbc">
        <baseproperties>
            <property name="odaUser" value="user"/>
            <property name="metadataBidiFormatStr" value="ILYNN"/>
            <property name="odaDriverClass" value="org.postgresql.Driver"/>
            <property name="odaJndiName" value=""/>
            <property name="odaPassword" value="pass"/>
            <property name="disabledMetadataBidiFormatStr" value=""/>
            <property name="contentBidiFormatStr" value="ILYNN"/>
            <property name="odaURL" value="jdbc:postgresql://localhost:5432/my-postgres-database"/>
            <property name="disabledContentBidiFormatStr" value=""/>
        </baseproperties>
    </profile>
</DataTools.ServerProfiles>

[hvbtup]

BTW this (unintented and superfluous saving of the property bindings) also happens if the data source is referenced from a library.

[speckyspooky]

The idea of the connection profile is not to remove an existing connection from the BIRT-report if the connection-profile is used.
It is an additional option and the existing connection will not removed.
This avoid by standard problems if the connection profile is not available then the local connection of the report can be used.
You have to remove the connection manually or to enter dummy values.

In some of our production plattforms we have up to 5 system stages (development, test, prelife, producton, sandbox).
And ih you have such constellation then every stage have an own connection profile and the report connection supports only the development-stage.
Yes, we change in every case after the first draft is done the local report connection and use the connection profile.

[alex-axiobit]

Ok, i understand the workaround, and while using dummy values might seem like a functional solution, it's not ideal.

When you enable a connection profile, you lose the ability to modify the local connection of the report. If the intention behind the local connection is to serve as a fallback in case no connection profile is available, it should remain editable.

Now, consider this: if you're storing your report design in a GitHub repository (and it's well known that storing sensitive information there is unsafe), then the local connection details of the report could pose a security risk. This information could unintentionally fall into the wrong hands. Not even the local connection of the report for the development should end up there, you can just use a connection profile for all cases.

From a security perspective, connection details should never be saved directly within the report design.

One more thing. If you edit the connection profile directly in the xml file and reload the design, the details in the BIRT JDBC Data Source window will be the ones from the connection profile xml, thus hiding the actual local connection details of the report design. And it will save that data in the the report design file, overwriting the initial details that we presumed to be a fallback. This sure it's not intended behavior.

[hvbtup]

From a security perspective, connection details should never be saved directly within the report design.

+1

This is not quite the same as using a connection profile, but just to demonstrate other ideas of setting up the connection properties dynamically and avoid storing sensitive information in the report, this is what we do (for our JDBC connection):

The report uses the builting sample DB for the data source properties.

We use a little bit of scripting (Javascript expresisons) in the connection properties. The scripts read the actual connection properties from the environment.