Go Down

Topic: New Password Library (Read 1 time) previous topic - next topic

HazardsMind

Oct 17, 2013, 05:04 am Last Edit: Feb 09, 2014, 11:04 pm by HazardsMind Reason: 1
Hi everyone, what I have here is new password library that supports multiple passwords and multiple users. I didn't really like the current password library mainly because it can only check one password  and it doesn't support any usernames. So I made a new one and after extensive testing, I think it should be shared.

Please note, I am still working on it to make it more code efficient, so I welcome any suggestions you may have. This is more of a rough draft version, because I am in the process of linking it with both LiquidCrystal (/ I2C) libraries and the current UTFT library.

So let me know what you think it.

UPDATE: Better version on last post.

chrisnet

Where is the Library I would have some time to try it!

HazardsMind

I put it as an attachment

PaulS

Quote
So let me know what you think it.

I think that this isn't the place to discuss new libraries. Development/Other software development is.

The old library would have multiple instances. Each instance could be updated/checked if there was a valid reason to have multiple passwords.

robtillaart

saw several things, one that catched my eye:
1)
passTemp[((Number_of_Passwords != 0) ? Number_of_Passwords : 0) + NOP_Inc]
equals
passTemp[Number_of_Passwords + NOP_Inc]

2)
// SetPassword and SetUser are technically not needed functions, because AddPassword takes care of both passwords and users
why add them if they are not needed?

3)
do not understand the detailed working esp addressing of the array elements (didn't dive into it) but I assume strcpy() or strncpy() would eleminate a lot of loops. a bit like
int n = (i % (( Num_of_Users + User_Inc) * Max_Lenght_of_username))/Max_Users;
strncpy(user, usertemp[n], j );
Rob Tillaart

Nederlandse sectie - http://arduino.cc/forum/index.php/board,77.0.html -
(Please do not PM for private consultancy)

HazardsMind

#5
Oct 18, 2013, 08:22 pm Last Edit: Oct 18, 2013, 10:51 pm by HazardsMind Reason: 1
Funny you should say that, because after I posted this, I began to rewrite the library. I got rid of set user and set password and I'm trying to see if I can cut the code down by storing the passwords and usernames in a structure. It works great until I try to add a new password to the list. That's when I'm guessing the memory is leaking.

After much debugging I noticed that if I add four password in the sketch, it works fine. But once I manually enter a password, the password I entered always matches what was stored.

I did a print out of what I entered and got this. These are the four passwords I stored at compile time.
1234 (what I enter)    1234(what is stored)
5678.    5678. = user found
abcd.     abcd = user found
Asdf.     Asdf =user found

Now I add a new password 8520, It gets stored but now if I enter an actual wrong password it over writes 8520 and says that the password was found every time.

I really don't know how to solve this problem other than to just not have the user be able to store new passwords.

HazardsMind

#6
Oct 19, 2013, 12:41 am Last Edit: Oct 19, 2013, 04:46 am by HazardsMind Reason: 1
Any thoughts as to why this is happening?
There is always a snag.


I figured it out... kinda, I went back to my original version and just modified it but kept the char * arrays instead of using a structure. I still want to understand what the problem was, I'm still thinking it was memory leakage issues.

HazardsMind

#7
Nov 08, 2013, 10:45 pm Last Edit: Nov 09, 2013, 07:47 pm by HazardsMind Reason: 1
UPDATE: (Actually finished it almost two weeks ago)
My password library is technically done, but now I'm deciding whether or not I should allow the user to choose how the data is stored. Right now both the passwords and usernames are stored in the heap, rather than the stack. However, I am thinking maybe I should allow the user to have a choice of where they store their data. The heap seems to take up more compile memory, but it also seems more efficient, and less likely to cause memory problems. Whereas the if the data was stored in the stack via 2D arrays, then it would take up less memory, but may cause problems later.

So if anyone thinks its a good idea to implement, let me know, if not then I'll keep the library as is.

Oh, I decided to not implement the LCD or Keypad libraries in my library, mainly because not everyone uses the standard LCD and Keypad libraries. But it will still work with them regardless of the library(s) used.

HazardsMind

#8
Mar 15, 2014, 07:28 pm Last Edit: Mar 24, 2014, 08:21 am by HazardsMind Reason: 1
Update!

I've been going through all my past libraries and I decided to add some more things to this library. I  added a few new features, that I think many will enjoy.

Let me know what you think.

Go Up