Thread: Re: [psa-devel]Reset Password
Brought to you by:
koivi
Menu
▾
▴
phpsecurityadm-devel
|
From: Justin K. <ju...@ko...> - 2003-05-22 15:37:15
|
OK, I finally got a chance to start working on the password reset stuff. I will be working on it today, and hopefully have it all cleaned up and committed to CVS before I go home today. (Or course, if depends on what else I have going on here. I find it really nice to be able to work on what started as a personal project and be able to use and debug it at work ;) |
|
From: Justin K. <ju...@ko...> - 2003-05-23 17:06:15
|
OK, I have now updated the CVS (major update). I finished cleaning up the password reset functionality (test it out). I also slightly changed the API of the Error() method to facilitate for multiple error messages (using arrays). Be sure to start with a fresh database structure from the schema file because there were a couple small changes there. Also, all the PO files have been updated, so I will post an anncouncement for translators to check out the latest files on the sourceforge web site. Also, if anyone on the list knows how to set the damn write access for sourceforge CVS, please let me know how! I want each translator to be able to update their PO file as necessary, but that's all they need access to. The sf.net docs are confusing to me for some reason. Well, that's all.. big CVS update - start from scratch when testing - we'll worry about upgrade stuff later. Anyone wanna tackle doc writing? ;) Happy testing!! Justin Koivisto |
|
From: Albert L. <al...@pl...> - 2003-05-23 19:53:10
|
On testing, first thing I've noticed is that installing the db is a serious pain even for people who know what they are doing. I'd like to get rid of the part that takes the schema from the include path. For a first time install you shouldn't have to change the permissions on a folder. Second, the manual update of the password isn't working. Haven't looked that far into the problem but thought I should report it. Alby On 5/23/03 1:06 PM, "Justin Koivisto" <ju...@ko...> wrote: > OK, I have now updated the CVS (major update). I finished cleaning up > the password reset functionality (test it out). I also slightly changed > the API of the Error() method to facilitate for multiple error messages > (using arrays). > > Be sure to start with a fresh database structure from the schema file > because there were a couple small changes there. > > Also, all the PO files have been updated, so I will post an > anncouncement for translators to check out the latest files on the > sourceforge web site. > > Also, if anyone on the list knows how to set the damn write access for > sourceforge CVS, please let me know how! I want each translator to be > able to update their PO file as necessary, but that's all they need > access to. The sf.net docs are confusing to me for some reason. > > Well, that's all.. big CVS update - start from scratch when testing - > we'll worry about upgrade stuff later. > > Anyone wanna tackle doc writing? ;) > > Happy testing!! > > Justin Koivisto |
|
From: Justin K. <ju...@ko...> - 2003-05-23 20:32:02
|
Albert Lash wrote: > On testing, first thing I've noticed is that installing the db is a serious > pain even for people who know what they are doing. I'd like to get rid of > the part that takes the schema from the include path. For a first time > install you shouldn't have to change the permissions on a folder. Well, I have updated the config file for a little better explanation. I don't think that this is a big deal since if you run the install_db from command line like suggested, then all you need to do is point it to any directory that you can write to. Using a web browser is when it becomes a pain in the arse. Maybe we should concentrate on the documentation for the package to help explain how things work and how to get them to work. > Second, the manual update of the password isn't working. Haven't looked that > far into the problem but thought I should report it. OK, I see that the password was changing, but the user kept getting set to inactive - if you weren't an admin. I fixed that in the user_edit_conection.php script so that should stop happening. |
|
From: Albert L. <al...@pl...> - 2003-05-24 16:46:01
|
Unfortunately not that many people have the cgi version of php installed. If they have to load it up in the browser it should still work as long as there isn't any copying going on and the file is in a webserver accessible directory which it probably would be since they are going to access the admin pages. > Well, I have updated the config file for a little better explanation. I > don't think that this is a big deal since if you run the install_db from > command line like suggested, then all you need to do is point it to any > directory that you can write to. Using a web browser is when it becomes > a pain in the arse. You're right. I'm horrible at writing docs and usually make things more complicated than they need to be but will give it a shot when I get a second. > Maybe we should concentrate on the documentation for the package to help > explain how things work and how to get them to work. > Hmm, for me its not changing at all. I'll update to see if your change fixes it for me. > OK, I see that the password was changing, but the user kept getting set > to inactive - if you weren't an admin. I fixed that in the > user_edit_conection.php script so that should stop happening. |
|
From: Justin K. <ju...@ko...> - 2003-05-27 13:10:34
|
Albert Lash wrote: >>Well, I have updated the config file for a little better explanation. I >>don't think that this is a big deal since if you run the install_db from >>command line like suggested, then all you need to do is point it to any >>directory that you can write to. Using a web browser is when it becomes >>a pain in the arse. > Unfortunately not that many people have the cgi version of php installed. If > they have to load it up in the browser it should still work as long as there > isn't any copying going on and the file is in a webserver accessible > directory which it probably would be since they are going to access the > admin pages. Actually, anyone using Windows will have the cli version installed, and I'm not sure, but the newest php builds the cli version from source by default as well (located in the php-4.3.x/sapi/cli directory). When Metabase parses an XML schema file, it writes a copy of it in order to use it if there are updates run at a later time. This would make it easier to update from previous versions if we change the field types or make other changes. >>Maybe we should concentrate on the documentation for the package to help >>explain how things work and how to get them to work. >> > You're right. I'm horrible at writing docs and usually make things more > complicated than they need to be but will give it a shot when I get a > second. >>OK, I see that the password was changing, but the user kept getting set >>to inactive - if you weren't an admin. I fixed that in the >>user_edit_conection.php script so that should stop happening. > Hmm, for me its not changing at all. I'll update to see if your change fixes > it for me. It had to do with the user not being shown the "activate" checkbox in the form. When the form was posted, it always assumed that it was there, so when the values wasn't set, it deactivated a user any time they tried to update their password. *Note* when sending a reply, bottom post rather than top post, it will keep the natural flow of the conversation. ;) |
|
From: Albert L. <al...@pl...> - 2003-05-29 15:23:06
|
Hi Justin, What's next for PSA? Do you want to keep testing CVS before we release? Some small additions we should include now are a prefix setting so the app can be moved to different folders with reference to the security folder. Also, it would be cool to add wildcards to the site structure. We both like mod_rewrite so we should also think about how to take care of that. Albert |
|
From: Justin K. <ju...@ko...> - 2003-05-29 16:22:56
|
Albert Lash wrote: > What's next for PSA? Do you want to keep testing CVS before we release? There are still some things that can be cleaned up with the password reset. Really, they are minor, but all the form fields and variables used in the GUI pages should be prefixed with PSA_ so it doesn't clash with other applications. Other than that, it is time to start doing some documentation. > Some small additions we should include now are a prefix setting so the app > can be moved to different folders with reference to the security folder. Do you mean like $PSA_PATH in index.php on line 24 and _restrict.php on line 4? > Also, it would be cool to add wildcards to the site structure. We both like > mod_rewrite so we should also think about how to take care of that. This is what I mean about documentation... That's already done and implemented. In fact, I think it was even in the last release. ;) |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X