Hello again.
I will post today a serie of what seems to me bugs (remember that i am using clarion6, so maybe is related) , and later also i will post about the calendarclass findings. Here I want to submit to you the change i introduced in sysruntime/runtime, not as a result of bug finding, but as i need i had.
The software i am writing is for currency exchange desk and is as such i have to certificate the sw at Croatian central bank. So i thought i will have problems during certification with 2 things:
1-the db.properties file is plain text
2-the initial logging to the system has postgres password as readable text
I have studied the sys/runtime and i have found that 2 simple changes to them allows me to manage myself the logging and connection storing.
1- Sysruntime CConfigStore.java
protected static Map<String,CConfigImpl> config = new HashMap<String, CConfigImpl>(); //config is now protected
2-runtime Jdbcsource.java
public static AbstractSourceFactory factory=new PgSourceFactory(); //is now public
Then in my main frame before the "connecting to database…" message i do the following:
The MyConfigStore is my class out of runtime:
public class MyConfigStore extends CConfigStore {
public static CConfigImpl getMyInstance(String name,QiqoK qbf)
{
name=name.toLowerCase();
synchronized(config) {
CConfigImpl result = config.get(name);
if (result==null) {
result=new MyFileConfigImpl("db",qbf);
config.put(name,result);
}
return result;
}
}
}
and the MyFileConfigImpl is my class that instead of writing to text file in plain text, encrypts and decrypts the text. At the end the db.properties is something as:
cb637a3c08ed262ba21d9ca267bc117bb87f5c369b7f777f9905d3e224f29eebb7f9733b262dce48918eac169e71a1c1
e2c394ca33ad5d47e5f4bbbaea37a2a7864fafefd08a1f458f84b03891e019c22d0b8e0e637383f5
b780ce572cc069185f960e3267202b50f86b422ec1c0135fc933570eab01995ed25a1d9c664a05ca
The MyPgSourceFactory is a my class, addapted from yours, that ask for some supervisor login before enabling connection to database, and the password field has setPassword property enabled.
I think this is elegant solution that allows anyone to implement theirs login facility, while by default living yours. What you think about? Could the two changes of above be included in the next release?
Thanks
Nenad
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This will allow you to register a custom ConfigImpl store
2: For logging of password; I am surprised yours is logging password. My app does not and I run my app on high debug. Can you please provide an example log ('*' out the password if you need to).
Generally way to deal with logging is to tune log level. See org.jclarion.clarion.log.Debug for example on how to do this.
I.e. in here you see:
Properties p = new Properties();
p.setProperty("handlers","java.util.logging.ConsoleHandler");
p.setProperty(".level","INFO");
p.setProperty("org.jclarion.level","FINEST");
p.setProperty("java.util.logging.ConsoleHandler.level","FINEST");
p.setProperty("java.util.logging.ConsoleHandler.formatter","org.jclarion.clarion.log.ClarionFormatter");
SharedOutputStream sos = new SharedOutputStream();
p.save(sos,"temp");
try {
LogManager.getLogManager().readConfiguration(sos.getInputStream());
} catch (SecurityException e) {
e.printStackTrace();
} catch (IOException e) {
e.printStackTrace();
}
Simply add another config setting thus to disable JDBC logging for example:
1. OK i will try this.
2.You can look at db.properties of the test i have sent to you. the la0603fi2508 is the password. I will try the p.setProperty("org.jclarion.clarion.jdbc.level","OFF");.
But still when you first time start the appliction, the windows from PgSourceFinder pops up and when you add a new source the password field is clear text. And also i inserted some login feature so that i am sure that only certain people can set the database. So how can i customize the PgSourceFinder without making public the factory?
Nenad
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
db.properties is not a log file. It is the file where the system memorizes the password for next time.
I suspect what you want to do is load in a custom CConfigImpl for dealing with passwords so password is not stored in plain text on the filesystem. Options for a custom CConfigImpl is that it either uses an encrypted file, or just hard codes the password in.
To suppress PgSourceFinder or load your own a number of options:
1. Custom CConfigImpl will never return a blank string on calls to getProperty(). Inside getProperty() you implement you own source finder/overload PgSourceFinder and add your custom logic
2. Create your own org.jclarion.clarion.jdbc.PgSourceFactory in your own custom java code. Java class loader will always load and link the first matching object in its class path. So a very dodgy technique of overloading is to copy source, and make sure your copied/modified source is in the class loader first. It is a very dodgy technique though and most java programmers will strongly discourage it. I think 1) above is a much better solution.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello again.
I will post today a serie of what seems to me bugs (remember that i am using clarion6, so maybe is related) , and later also i will post about the calendarclass findings. Here I want to submit to you the change i introduced in sysruntime/runtime, not as a result of bug finding, but as i need i had.
The software i am writing is for currency exchange desk and is as such i have to certificate the sw at Croatian central bank. So i thought i will have problems during certification with 2 things:
1-the db.properties file is plain text
2-the initial logging to the system has postgres password as readable text
I have studied the sys/runtime and i have found that 2 simple changes to them allows me to manage myself the logging and connection storing.
1- Sysruntime CConfigStore.java
protected static Map<String,CConfigImpl> config = new HashMap<String, CConfigImpl>(); //config is now protected
2-runtime Jdbcsource.java
public static AbstractSourceFactory factory=new PgSourceFactory(); //is now public
Then in my main frame before the "connecting to database…" message i do the following:
compile('java-end',java)
@java-code 'MyConfigStore.getMyInstance("db.properties",Main.qbf);'
@java-code 'MyPgSourceFactory factory=new MyPgSourceFactory();'
@java-code 'factory.hostName=Main.hostName.toString();
@java-code 'factory.hostIp=Main.hostIP.toString();
@java-code 'org.jclarion.clarion.jdbc.JDBCSource.factory=(AbstractSourceFactory)factory;'
java-end
The MyConfigStore is my class out of runtime:
public class MyConfigStore extends CConfigStore {
public static CConfigImpl getMyInstance(String name,QiqoK qbf)
{
name=name.toLowerCase();
synchronized(config) {
CConfigImpl result = config.get(name);
if (result==null) {
result=new MyFileConfigImpl("db",qbf);
config.put(name,result);
}
return result;
}
}
}
and the MyFileConfigImpl is my class that instead of writing to text file in plain text, encrypts and decrypts the text. At the end the db.properties is something as:
cb637a3c08ed262ba21d9ca267bc117bb87f5c369b7f777f9905d3e224f29eebb7f9733b262dce48918eac169e71a1c1
e2c394ca33ad5d47e5f4bbbaea37a2a7864fafefd08a1f458f84b03891e019c22d0b8e0e637383f5
b780ce572cc069185f960e3267202b50f86b422ec1c0135fc933570eab01995ed25a1d9c664a05ca
The MyPgSourceFactory is a my class, addapted from yours, that ask for some supervisor login before enabling connection to database, and the password field has setPassword property enabled.
I think this is elegant solution that allows anyone to implement theirs login facility, while by default living yours. What you think about? Could the two changes of above be included in the next release?
Thanks
Nenad
Can I suggest some alternative solutions? Exposing internal fields in objects is generally considered bad programming practice.
For 1 above: I add a new static method onto CConfigStore.java :
public static void setInstance(String name,CConfigImpl impl)
{
synchonized(config) {
config.put(name,impl);
}
}
This will allow you to register a custom ConfigImpl store
2: For logging of password; I am surprised yours is logging password. My app does not and I run my app on high debug. Can you please provide an example log ('*' out the password if you need to).
Generally way to deal with logging is to tune log level. See org.jclarion.clarion.log.Debug for example on how to do this.
I.e. in here you see:
Simply add another config setting thus to disable JDBC logging for example:
Just need to isolate the log statement in question and setup appropriate logging to disable it.
1. OK i will try this.
2.You can look at db.properties of the test i have sent to you. the la0603fi2508 is the password. I will try the p.setProperty("org.jclarion.clarion.jdbc.level","OFF");.
But still when you first time start the appliction, the windows from PgSourceFinder pops up and when you add a new source the password field is clear text. And also i inserted some login feature so that i am sure that only certain people can set the database. So how can i customize the PgSourceFinder without making public the factory?
Nenad
db.properties is not a log file. It is the file where the system memorizes the password for next time.
I suspect what you want to do is load in a custom CConfigImpl for dealing with passwords so password is not stored in plain text on the filesystem. Options for a custom CConfigImpl is that it either uses an encrypted file, or just hard codes the password in.
To suppress PgSourceFinder or load your own a number of options:
1. Custom CConfigImpl will never return a blank string on calls to getProperty(). Inside getProperty() you implement you own source finder/overload PgSourceFinder and add your custom logic
2. Create your own org.jclarion.clarion.jdbc.PgSourceFactory in your own custom java code. Java class loader will always load and link the first matching object in its class path. So a very dodgy technique of overloading is to copy source, and make sure your copied/modified source is in the class loader first. It is a very dodgy technique though and most java programmers will strongly discourage it. I think 1) above is a much better solution.