diff --git a/Sda1/sda1.xml b/Sda1/sda1.xml
index ca75ad9331b190430dab0ebf0661613949d11928..0941356b0c03b4cdeae9f43c6692a65625de18eb 100644
--- a/Sda1/sda1.xml
+++ b/Sda1/sda1.xml
@@ -12039,57 +12039,84 @@ public class InsertPerson extends JFrame {
</qandadiv>
</qandaset>
- <qandaset defaultlabel="qanda" xml:id="quandaentry_ArchSecurity">
+ <section xml:id="sectArchitectSecurityConsiderations">
<title>Architectural security considerations</title>
- <qandadiv>
- <qandaentry>
- <question>
- <para>In <xref linkend="exerciseInsertLoginCredentials"/> we
- achieved end user credential protection. How about the overall
- application security? Provide improvement proposals if
- appropriate. Hint: Consider the way credentials are being
- supplied.</para>
- </question>
+ <qandaset defaultlabel="qanda" xml:id="quandaentry_ArchSecurity">
+ <qandadiv>
+ <qandaentry>
+ <question>
+ <para>In <xref linkend="exerciseInsertLoginCredentials"/> we
+ achieved end user credential protection. How about the
+ overall application security? Provide improvement proposals
+ if appropriate. Hint: Consider the way credentials are being
+ supplied.</para>
+ </question>
- <answer>
- <para>Connecting the client to our database server solely
- depends on credentials <coref
- linkend="databaseUserHdmPassword"/> being stored in a
- properties file
- <filename>database.properties</filename>:</para>
+ <answer>
+ <para>Connecting the client to our database server solely
+ depends on credentials <coref
+ linkend="databaseUserHdmPassword"/> being stored in a
+ properties file
+ <filename>database.properties</filename>:</para>
- <programlisting language="none">PersistenceHandler.jdbcUrl=jdbc:mysql://localhost:3306/hdm
+ <programlisting language="none">PersistenceHandler.jdbcUrl=jdbc:mysql://localhost:3306/hdm
PersistenceHandler.username=hdmuser <co xml:id="databaseUserHdmUsername"/>
PersistenceHandler.password=<emphasis role="bold">XYZ</emphasis> <co
- xml:id="databaseUserHdmPassword"/></programlisting>
-
- <para>This properties file is user accessible and contains the
- password in clear text. Arbitrary applications connecting to
- the database server using this account do have all permissions
- being granted to <code>hdmuser</code> <coref
- linkend="databaseUserHdmUsername"/>. In order for our
- application to work correctly the set of granted permissions
- contains at least inserting datasets. Thus new users e.g.
- <code>smith</code> including credentials may be inserted.
- Afterwards the original application can be started by logging
- in as <code>smith</code>.</para>
-
- <para>Conclusion: The current application architecture is
- seriously flawed with respect to security.</para>
-
- <para>Rather then using a common database account
- <code>hdmuser</code> we may configure per-user accounts on the
- database server having individual user credentials. This way
- user credentials are no longer stored in our
- <code>Person</code> table but are being managed by the
- database server's user management and privilege facilities.
- This completely avoids storing credentials on the client
- side.</para>
- </answer>
- </qandaentry>
- </qandadiv>
- </qandaset>
+ xml:id="databaseUserHdmPassword"/></programlisting>
+
+ <para>This properties file is user accessible and contains
+ the password in clear text. Arbitrary applications
+ connecting to the database server using this account do have
+ all permissions being granted to <code>hdmuser</code> <coref
+ linkend="databaseUserHdmUsername"/>. In order for our
+ application to work correctly the set of granted permissions
+ contains at least inserting datasets. Thus new users e.g.
+ <code>smith</code> including credentials may be inserted.
+ Afterwards the original application can be started by
+ logging in as <code>smith</code>.</para>
+
+ <para>Conclusion: The current application architecture is
+ seriously flawed with respect to security.</para>
+
+ <para>Rather then using a common database account
+ <code>hdmuser</code> we may configure per-user accounts on
+ the database server having individual user credentials. This
+ way user credentials are no longer stored in our
+ <code>Person</code> table but are being managed by the
+ database server's user management and privilege facilities.
+ This completely avoids storing credentials on the client
+ side.</para>
+ </answer>
+ </qandaentry>
+ </qandadiv>
+ </qandaset>
+ </section>
+
+ <section xml:id="sectRelationadatal2Xml">
+ <title>Converting relational data to XML</title>
+
+ <qandaset defaultlabel="qanda" xml:base="qandaRelationaldata2Xml"
+ xml:id="qandaRelationaldata2Xml">
+ <title>Reversing Xml to Rdbms exercise</title>
+
+ <qandadiv>
+ <qandaentry>
+ <question>
+ <label>Exporting RDBMS data to XML.</label>
+
+ <para>Reverse exercise <xref
+ linkend="qandaXmldata2relational"/> to read Rdbms data via
+ JDBC and export corresponding XML data using Jdom.</para>
+ </question>
+
+ <answer>
+ <para>Not yet published.</para>
+ </answer>
+ </qandaentry>
+ </qandadiv>
+ </qandaset>
+ </section>
<section xml:id="sda1SaxRdbms">
<title>SAX and RDBMS</title>