search

crised / electrical

Electrical M2M software to get an Electrical Bill approximation
0 stars 0 forks source link

password change / recovery #17

Closed crised closed 10 years ago

crised commented 10 years ago

please implement this in basic functionality

blabno commented 10 years ago

Password is stored in DB as SHA256 hash, but during registration we're sending auto-generated password in plain text to new user. It's not sate of art but I wanted to implement it as simple as possible. Also I'm not using JMS to put mail message there before sending it to mail server (which I normally do). Again, it's for sake of simplicity, especially that it's the admin that will register users.

crised commented 10 years ago

Yes np. Btw JNI seems difficult. C simple code to read and insert data to postgresql. @radu can handle that. On Sep 18, 2013 11:14 AM, "Bernard Labno" notifications@github.com wrote:

Password is stored in DB as SHA256 hash, but during registration we're sending auto-generated password in plain text to new user. It's not sate of art but I wanted to implement it as simple as possible. Also I'm not using JMS to put mail message there before sending it to mail server (which I normally do). Again, it's for sake of simplicity, especially that it's the admin that will register users.

— Reply to this email directly or view it on GitHubhttps://github.com/crised/electrical/issues/17#issuecomment-24666916 .

blabno commented 10 years ago

With JNI you only need to implement single method in C.

crised commented 10 years ago

Maybe you can write pseudo code so I and Radu can understand this.

Postgresql C interface is ultra easy, and modbus C librarys are great too don't foresee any problem here. On Sep 18, 2013 11:24 AM, "Bernard Labno" notifications@github.com wrote:

With JNI you only need to implement single method in C.

— Reply to this email directly or view it on GitHubhttps://github.com/crised/electrical/issues/17#issuecomment-24667817 .

rnicolau commented 10 years ago

I think I see what @blabno means, implement one JNI function to interface as: Java <-> library with a JNI function <-> libmodbus Can be done but you still need to write (at least) the libmodbus related code (initialize, read, etc). My advice will be to keep this part as a native C/C++ application.

blabno commented 10 years ago

I've implemented JNI skelton: https://github.com/crised/electrical/commit/29fbca4d98da706e7de7418087bf162f3e4bf43c

rnicolau commented 10 years ago

@crised we need to decide which way to go:

  1. lightweight native daemon that pushes modbus data to a PostgreSQL database; in this case there is no need for JNI as the java server should read the database directly
  2. java server gets the modbus data from the JNI call; in this case the JNI must be completed to handle the initialization/cleanup lifecycle and error return path
crised commented 10 years ago

Solution 1 On Sep 18, 2013 1:54 PM, "rnicolau" notifications@github.com wrote:

@crised https://github.com/crised we need to decide which way to go:

  1. lightweight native daemon that pushes modbus data to a PostgreSQL database; in this case there is no need for JNI as the java server should read the database directly
  2. java server gets the modbus data from the JNI call; in this case the JNI must be completed to handle the initialization/cleanup lifecycle and error return path

— Reply to this email directly or view it on GitHubhttps://github.com/crised/electrical/issues/17#issuecomment-24680890 .

blabno commented 10 years ago

Although I totally don't understand how come it's easier to stick database in the middle instead of implementing single method I accept your decision.

crised commented 10 years ago

Database is more robust design. Its a standard program to insert values in pg.

Debugging with serial its not an easy thing. That's why I prefer 100% native.

Remote access to the db is even a simpler design. No need for json and client ssl certificate with Apache since device will be a db server. Please comment On Sep 19, 2013 9:33 AM, "Bernard Labno" notifications@github.com wrote:

Although I totally don't understand how come it's easier to stick database in the middle instead of implementing single method I accept your decision.

— Reply to this email directly or view it on GitHubhttps://github.com/crised/electrical/issues/17#issuecomment-24735199 .

blabno commented 10 years ago

Do you mean, that each device will access the same central database? If so then indeed it's easier. I thought that you want to install separate databases on each device.

crised commented 10 years ago

That is not so robust, device must have local pg db, because the read serial / insert db is one thread simple sync program. Db must always be available.

So we need to have 2 data sources, one db in the device and another in the server. On Sep 19, 2013 9:47 AM, "Bernard Labno" notifications@github.com wrote:

Do you mean, that each device will access the same central database? If so then indeed it's easier. I thought that you want to install separate databases on each device.

— Reply to this email directly or view it on GitHubhttps://github.com/crised/electrical/issues/17#issuecomment-24735933 .

crised commented 10 years ago

Wondering how to programmatically change the ip of the data source... On Sep 19, 2013 9:50 AM, "Cristián Edwards" crised@gmail.com wrote:

That is not so robust, device must have local pg db, because the read serial / insert db is one thread simple sync program. Db must always be available.

So we need to have 2 data sources, one db in the device and another in the server. On Sep 19, 2013 9:47 AM, "Bernard Labno" notifications@github.com wrote:

Do you mean, that each device will access the same central database? If so then indeed it's easier. I thought that you want to install separate databases on each device.

— Reply to this email directly or view it on GitHubhttps://github.com/crised/electrical/issues/17#issuecomment-24735933 .

blabno commented 10 years ago

No way, we should not allow for server to connect to some devices DB. That is bad design. It's the device that should contact server and send data. BTW. why did you resign from sending data from devices "C" program to server via REST?

crised commented 10 years ago

Because radu suggested.

Ok then yiucan do simple java script that read values from db and post it to server. Either basic auth or client ssl auth. Keep in mind that we will have a client certificate anyways. On Sep 19, 2013 9:59 AM, "Bernard Labno" notifications@github.com wrote:

No way, we should not allow for server to connect to some devices DB. That is bad design. It's the device that should contact server and send data. BTW. why did you resign from sending data from devices "C" program to server via REST?

— Reply to this email directly or view it on GitHubhttps://github.com/crised/electrical/issues/17#issuecomment-24736571 .

crised commented 10 years ago

I think java se should make a jdbc SELECT query and pack the results in json and post to diff urls.

If it fails then re do operation, and if sucess mark the row as sent. This operation can perform every 30 secs. On Sep 19, 2013 10:02 AM, "Cristián Edwards" crised@gmail.com wrote:

Because radu suggested.

Ok then yiucan do simple java script that read values from db and post it to server. Either basic auth or client ssl auth. Keep in mind that we will have a client certificate anyways. On Sep 19, 2013 9:59 AM, "Bernard Labno" notifications@github.com wrote:

No way, we should not allow for server to connect to some devices DB. That is bad design. It's the device that should contact server and send data. BTW. why did you resign from sending data from devices "C" program to server via REST?

— Reply to this email directly or view it on GitHubhttps://github.com/crised/electrical/issues/17#issuecomment-24736571 .

crised commented 10 years ago

I'd use jackson for json in both sides. On Sep 19, 2013 10:02 AM, "Cristián Edwards" crised@gmail.com wrote:

Because radu suggested.

Ok then yiucan do simple java script that read values from db and post it to server. Either basic auth or client ssl auth. Keep in mind that we will have a client certificate anyways. On Sep 19, 2013 9:59 AM, "Bernard Labno" notifications@github.com wrote:

No way, we should not allow for server to connect to some devices DB. That is bad design. It's the device that should contact server and send data. BTW. why did you resign from sending data from devices "C" program to server via REST?

— Reply to this email directly or view it on GitHubhttps://github.com/crised/electrical/issues/17#issuecomment-24736571 .

rnicolau commented 10 years ago

@blabno having the database in the middle is not necessary easier, but more robust as there will be a lightweight process that will only read modbus and push data to the database. And this process can be installed as a service and have it restarted (if it exits for any reason) by init/systemd/upstart or whatever is there on the desired linux distro. This will ensure that data will never be lost, worst case scenario is that it will be stored locally if the network connection fails.

crised commented 10 years ago

Yep On Sep 19, 2013 12:17 PM, "rnicolau" notifications@github.com wrote:

@blabno https://github.com/blabno having the database in the middle is not necessary easier, but more robust as there will be a lightweight process that will only read modbus and push data to the database. And this process can be installed as a service and have it restarted (if it exits for any reason) by init/systemd/upstart or whatever is there on the desired linux distro. This will ensure that data will never be lost, worst case scenario is that it will be stored locally if the network connection fails.

— Reply to this email directly or view it on GitHubhttps://github.com/crised/electrical/issues/17#issuecomment-24746780 .