phpsecurityadm-devel Mailing List for SecurityAdmin for PHP
Brought to you by:
koivi
Menu
▾
▴
phpsecurityadm-devel — Developer's mailing list for phpSecurityAdm
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(9) |
Apr
|
May
(18) |
Jun
(5) |
Jul
(3) |
Aug
(16) |
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Justin K. <ju...@ko...> - 2004-07-30 13:28:57
|
So far, PSA4 is functional - except for the supplemental UI. The class has been reworked to interface with PEAR::MDB instead of Metabase, and so far the _restrict.php file is working. The next step will be to get all the UI pages arranged and functional. Also, I have some work to do on the SQL queries that are used in the class, and will get to them when I start work on the UI. I have been thinking of possibly setting up another restriction method that checks for GET or POST variables. Then there would be 4 or 5 access methods instead of just 2: 1. No access 2. Full access 3. Read only (no GET or POST allowed) 4. Read and GET 5. Read and POST This option would allow for better control and more flexibility in CMS systems. There hasn't been any planning for this yet, it's just a thought at this point. Version 4 will have API changes because I felt that a good audit was needed. Therefore, don't expect to upgrade PSA to work with custom apps that accessed the class methods directly. However, if you only use PSA's _restrict.php and the supplied UI, then things should work without hitch. Obviously, there is going to be a lot of testing on my end before I release even alpha or beta code. I don't have sf.net CVS setup where I am developing, and I don't have the time to set it up right now, so you'll all have to be in the dark for a while. If anyone out there has any feature requests, now would be a great time to submit them. Thanks to all you who've helped out in the past! |
|
From: Justin K. <ju...@ko...> - 2004-04-22 13:41:44
|
It's been a while since I had any time to work on PSA, but I will start doing it soon again. My plans at this point: 1. Get rid of using Metabase in favor of the more efficient and easier to come by PEAR::MDB http://pear.php.net/package/MDB 2. Fix all the INSERT queries back to the INSERT INTO table (field1, field2) VALUES (val1, val2) syntax. 3. Change the GUI to be simpler and more straight forward. 4. Audit the code for things that aren't that efficient. I will search through PEAR to see what is available for this type of application and decide (depending on what is available) on how to proceed with possible new features. I will also search PEAR for a gettext type of package and possibly put that into place, depending on what I find and what the pros and cons are. I'm still a couple weeks off on this (at least), but it is part of a project that I will be working on this summer. If anyone is interested in jumping on board, let me know when I announce that I have started work. |
|
From: Justin K. <ju...@ko...> - 2003-08-22 21:00:47
|
Alex Ezell wrote: > On Wednesday, August 20, 2003, 11:08:08 AM, Albert wrote: > > >>I'm guessing you are crazedwombat? > > > Yes, sorry. > You have been added to the project as a developer now. Thanks. |
|
From: Justin K. <ju...@ko...> - 2003-08-22 15:13:32
|
Albert Lash wrote: > I will need to add (at least - looking for additional input) these fields to > the psa_users table: Here are the fields that I use a lot in stuff like this: first_name last_name company address address2 city county state zip country phone fax email cell pager sex birth_date profession You'll need to add a config array to the config file like: array( 'first_name' = REQUIRED, 'last_name' = REQUIRED, 'company' = TRUE, 'address' = TRUE, 'address2' = TRUE, 'city' = TRUE, 'county' = FALSE, 'state' = TRUE, 'zip' = REQUIRED, 'country' = FALSE, 'phone' = FALSE, 'fax' = FALSE, 'email' = REQUIRED, 'cell' = FALSE, 'pager' = FALSE, 'sex' = FALSE, 'birth_date' = FALSE, 'profession' = FALSE ) you'd have to define the REQUIRED constant (I'd suggest something like -1 since TRUE =1 and FALSE =0). FALSE fields are skipped (for everything), TRUE and REQUIRED fields are the only ones displayed. When a form is posted, check against the config array to be sure all is satisfied. Push warnings for FALSE fields that were in the input, and errors for missing required fields. The form coding should make use of the VALUE, CHECKED and SELECTED attributes where values are taken from the posted information in case of error. The values for these attributes need to be checked agains submitted information to avoid warnings about non-defined variables. Hope this helps out. I've been just too damn busy to do much of anything anymore. :( |
|
From: Alex E. <ta...@sp...> - 2003-08-22 13:29:36
|
On Thursday, August 21, 2003, 8:40:39 AM, Albert wrote: > Alex - do you want us to add you as a developer? Sure. I am working quite a bit with PSA lately and so I would be glad to give back to the project. -- Alex http://www.spittingllamas.com "Formal Restrictions, contrary to what you might think, free you up by allowing you to concentrate on purer ideas." - Winter Sorbeck in Chip Kidd's The Cheese Monkeys |
|
From: Alex E. <ta...@sp...> - 2003-08-22 05:16:23
|
On Wednesday, August 20, 2003, 11:08:08 AM, Albert wrote: > I'm guessing you are crazedwombat? Yes, sorry. -- Alex http://www.spittingllamas.com "Formal Restrictions, contrary to what you might think, free you up by allowing you to concentrate on purer ideas." - Winter Sorbeck in Chip Kidd's The Cheese Monkeys |
|
From: Albert L. <al...@pl...> - 2003-08-22 03:06:51
|
Alex - do you want us to add you as a developer? |
|
From: Justin K. <ju...@ko...> - 2003-08-21 17:55:40
|
Albert Lash wrote: > In the current release of PSA, the settings do not update. This is because > in the settings table, the setting names are as follows: > > min_username_length > > And in the class, they are referenced as: > > PSA_min_username_length > > I'm going to update the schema and sql files accordingly. In this case, the class settings functions should be modified to use the correct field names. |
|
From: Alex E. <ta...@sp...> - 2003-08-21 08:33:15
|
On Wednesday, August 20, 2003, 1:43:39 PM, Albert wrote: > I will need to add (at least - looking for additional input) these fields to > the psa_users table: > Address_1 > Address_2 > Town > City > Zip > Country > Date of Birth > Company > Fax Could you make the fields list dynamic as part of an install procedure? Have some that are defaults, but let the user add custom fields if needed. Maybe just do this at an install level and not as something that could be constantly modified. > Not the exhaustive list, but a start. I'd like to setup a basic form that > users can customize that uses the addUser function. It would be cool to have > an array as part of the setup that can define which fields are required and > which are not. Then of course some intelligent way to produce an error and a > user friendly way to highlight which fields were missed, while retaining the > original inputs. Should be fairly easy to do this by dynamically setting the CSS class of the input fields based on some flag. > I just did this using PSA and my solution was very sloppy and bug prone. > This will be useful to the project because many web applications are > utilized by users who sign themselves up, or give themselves access. I am about to begin work on a project that would need this as well. To that end, I would love to help as best I can. -- Alex http://www.spittingllamas.com "Formal Restrictions, contrary to what you might think, free you up by allowing you to concentrate on purer ideas." - Winter Sorbeck in Chip Kidd's The Cheese Monkeys |
|
From: Albert L. <al...@pl...> - 2003-08-20 18:29:36
|
I will need to add (at least - looking for additional input) these fields to the psa_users table: Address_1 Address_2 Town City Zip Country Date of Birth Company Fax Not the exhaustive list, but a start. I'd like to setup a basic form that users can customize that uses the addUser function. It would be cool to have an array as part of the setup that can define which fields are required and which are not. Then of course some intelligent way to produce an error and a user friendly way to highlight which fields were missed, while retaining the original inputs. I just did this using PSA and my solution was very sloppy and bug prone. This will be useful to the project because many web applications are utilized by users who sign themselves up, or give themselves access. - Al On 8/20/03 12:37 PM, "Justin Koivisto" <ju...@ko...> wrote: > Albert Lash wrote: >> I would really appreciate help in designing and developing the open >> registration process, and modeling the database structure for the user >> Extensive user profile. > > Give me an idea of what you want to accomplish, and I will throw some > ideas or code out there for you. |
|
From: Justin K. <ju...@ko...> - 2003-08-20 16:49:42
|
Albert Lash wrote: > I would really appreciate help in designing and developing the open > registration process, and modeling the database structure for the user > Extensive user profile. Give me an idea of what you want to accomplish, and I will throw some ideas or code out there for you. |
|
From: Albert L. <al...@pl...> - 2003-08-20 15:30:32
|
For some reason, my first message didn't go through. Here it is: In the current release of PSA, the settings do not update. This is because in the settings table, the setting names are as follows: min_username_length And in the class, they are referenced as: PSA_min_username_length I'm going to update the schema and sql files accordingly. Albert I didn't change the database. Alex, are you still interested in being a developer? On 8/20/03 10:54 AM, "Alex Ezell" <ta...@sp...> wrote: > On Wednesday, August 20, 2003, 10:36:21 AM, Albert wrote: > >> I changed my mind. The rest of the class does not user the PSA_ prefix. I've >> removed it from the settings.php template. We can change the entire system >> over later if necessary. > > Can you clarify? What was the change that you are now changing back? |
|
From: Albert L. <al...@pl...> - 2003-08-20 15:19:40
|
Alex, I'm guessing you are crazedwombat? Albert |
|
From: Albert L. <al...@pl...> - 2003-08-20 15:19:04
|
In the current release of PSA, the settings do not update. This is because in the settings table, the setting names are as follows: min_username_length And in the class, they are referenced as: PSA_min_username_length I'm going to update the schema and sql files accordingly. Albert |
|
From: Albert L. <al...@pl...> - 2003-08-20 15:17:54
|
I would really appreciate help in designing and developing the open registration process, and modeling the database structure for the user Extensive user profile. Albert |
|
From: Alex E. <ta...@sp...> - 2003-08-20 14:59:17
|
On Wednesday, August 20, 2003, 10:36:21 AM, Albert wrote: > I changed my mind. The rest of the class does not user the PSA_ prefix. I've > removed it from the settings.php template. We can change the entire system > over later if necessary. Can you clarify? What was the change that you are now changing back? -- Alex http://www.spittingllamas.com "Formal Restrictions, contrary to what you might think, free you up by allowing you to concentrate on purer ideas." - Winter Sorbeck in Chip Kidd's The Cheese Monkeys |
|
From: Albert L. <al...@pl...> - 2003-08-20 14:42:54
|
I changed my mind. The rest of the class does not user the PSA_ prefix. I've removed it from the settings.php template. We can change the entire system over later if necessary. |
|
From: Justin K. <ju...@ko...> - 2003-08-04 13:03:37
|
Alex Ezell wrote: > I have modified the code to allow the user to supply a prefix for the > database tables. This change is only in the application code. I did > not make the change in the code that creates the tables to begin with. > So, the user would have to rename the tables manually within the DB, > and then use the config.php to give the application the prefix they > used. Obviously, there is more work to do to make it seamless to the > users, but I thought this might be a nice feature. In order to have this included in the next release of PSA, the database structure needs to be adjusted to handle it as well. If it doesn't, there will be way too many "why doesn't this work" messages coming to the lists. One way of going about this is to have the install script check the config file for an appropriate setting. If the setting is not 'psa', then it would read the file in, and use a regex to replace '<table>psa' with '<table>'.$table_prefix_var, then write the file back out. > I needed it because I am using PSA in a larger app that I am building, > and I want to have all the db tables of my app, including those used > by PSA, to have the same prefix so that installation is easier. > > I don't have a connection to CVS setup and as the implementation is > incomplete it wouldn't suit to check it in anyway. However, I could > provide the code I do have to anyone who wants it. Overall, it would be a handy option. All the queries in the class would need to be modified to support this and a vriable in the config file would need to be created, but other than that, only the install script would need any real work done to it. Sorry it took so long to get back to this, I just returned from a couple weeks vacation time I had coming. ;) Justin |
|
From: Alex E. <ta...@sp...> - 2003-07-31 18:01:30
|
On Thursday, July 31, 2003, 11:40:39 AM, Albert wrote: > Hi Alex, > Sorry to keep you waiting, I've emailed the project leader for his input. > I'd like to add this. Be right back... > I'll look into making you a developer in the mean time. Cool. > Does the app you're working on support lots of users? The next big > development we're planning for PSA is to allow users to sign themselves up, > and I would like to gather input on the design for this. It won't necessarily, but it sort of depends on how folks would implement it. It's really more of an intranet app, so I don't think there would ever be the need for it to support people registering themselves. I would be more than glad to help brainstorm how this should work though. -- Alex http://www.spittingllamas.com "Formal Restrictions, contrary to what you might think, free you up by allowing you to concentrate on purer ideas." - Winter Sorbeck in Chip Kidd's The Cheese Monkeys |
|
From: Alex E. <ta...@sp...> - 2003-07-28 14:41:11
|
On Monday, July 28, 2003, 9:57:30 AM, Albert wrote:
> Glad to hear you've got the system working well for you. Making the db
> prefix customizable is a useful feature.
> What may make sense is to make it easily customizable. In the default
> shipping, it would be set to "PSA_". If the user, like you have done, wants
> to have a different prefix, they can change the config, then manually update
> the schema.
> Post a bit of what you've done to the list and we'll see if it makes sense
> to go for it.
Okay,
Here is a little of what I have done. This is not comprehensive of my
changes, but gives the general idea.
IN CONFIG.PHP I ADDED
-----------------------------------------
'TblPrefix' => 'folio_',
-----------------------------------------
to the $PSA_SCR array
IN class.phpSecuirtyAdm.php I ADDED
-----------------------------------------
// The database table prefix stuff
if(isset($PSA_SCR['TblPrefix'])){
$this->TBL_PREFIX=$PSA_SCR['TblPrefix'];
}else{
$this->TBL_PREFIX='folio_';
}
-----------------------------------------
to force the prefix to whatever I wanted if the user left the config
blank. I am using PSA in another app, as most users probably are, so I
am using that apps shortname to prefix the db. This may not totally be
necessary, but it could help if someone deletes the setting from
config.php accidentally.
So, then in all the pages where DB calls are made, I added a line
similar to this one:
-----------------------------
$query='UPDATE '.$PSA_SCR['TblPrefix'].'psa_sessions SET expiry='.$expiry.', value='.$PSA_SESS_SQL->GetTextFieldValue($val).
-----------------------------
OR
-----------------------------
$query="SELECT pass, hash, active, lockcount, connection FROM ".$this->TBL_PREFIX."psa_users WHERE id=".$this->db->GetTextFieldValue($user);
-----------------------------
within the class.
It's really straightforward. Some of the issues I found were:
1. Ensuring that the $PSA_SCR was within the scope of some of the
functions, especially within sessions.php.
2. Working with the _sequence tables, I ended up just letting them be
something like _sequence_folio_whatever instead of making it a strict
prefix. The code for that was something like
------------------------------
$result=$this->db->GetSequenceNextValue($this->TBL_PREFIX.'psa_profiles_id',$id);
------------------------------
What do you think?
--
Alex
http://www.spittingllamas.com
"Formal Restrictions, contrary to what you might think,
free you up by allowing you to concentrate on purer ideas."
- Winter Sorbeck in Chip Kidd's The Cheese Monkeys
|
|
From: Alex E. <ta...@sp...> - 2003-07-25 17:59:11
|
I have modified the code to allow the user to supply a prefix for the database tables. This change is only in the application code. I did not make the change in the code that creates the tables to begin with. So, the user would have to rename the tables manually within the DB, and then use the config.php to give the application the prefix they used. Obviously, there is more work to do to make it seamless to the users, but I thought this might be a nice feature. I needed it because I am using PSA in a larger app that I am building, and I want to have all the db tables of my app, including those used by PSA, to have the same prefix so that installation is easier. I don't have a connection to CVS setup and as the implementation is incomplete it wouldn't suit to check it in anyway. However, I could provide the code I do have to anyone who wants it. -- Alex http://www.spittingllamas.com "Formal Restrictions, contrary to what you might think, free you up by allowing you to concentrate on purer ideas." - Winter Sorbeck in Chip Kidd's The Cheese Monkeys |
|
From: Justin K. <ju...@ko...> - 2003-06-23 14:23:13
|
Albert Lash wrote: > I made a release of 3.1 at SF today. I noticed that, thanks. I was actually thinking of doing that today when I got to work. > An additional thought I had was to > consider having "sites", so that the same PSA source could get used for > multiple sites. That would be smart I think. Sort of like a profile feature > for site structures. What do you think? I have thought about that, but haven't gotten around to planning it out yet. Part of the problem was that you'd have to pass the site's domain so you knew where the request was comming from. However, I didn't give it enoughthough to come up with a transparent, clever way of doing that yet. You can't rely on the HTTP_REFERER for it, and if it is at a central location, you can't rely on HTTP_HOST either... REQUEST_URI doesn't provide the domain, and SERVER_NAME wouldn't be any help either. Once I figured all that out, I stopped thinking of it because it wasn't necessary for me at the time. > I guess it wouldn't make much of a functional difference, but would make > managing the system much easier. The biggest thing is not to change the API, or at least keep it backward-compatible. There would likely be a bit of work to do on the hasRights method since that would be the only one that would really need modifying. The other thing to keep in mind is if we were to use XML site mapping, then there would have to be a way of managing that within the structure as well. It's all pretty complicated, but give it some thought and let me know what you come up with... I am still pretty swamped, but hope to lighten up a litle here in the next few weeks. |
|
From: Albert L. <al...@pl...> - 2003-06-23 14:03:49
|
Hi Justin, I made a release of 3.1 at SF today. An additional thought I had was to consider having "sites", so that the same PSA source could get used for multiple sites. That would be smart I think. Sort of like a profile feature for site structures. What do you think? I guess it wouldn't make much of a functional difference, but would make managing the system much easier. Albert |
|
From: Albert L. <al...@pl...> - 2003-06-05 20:52:33
|
On 6/5/03 12:19 PM, "Justin Koivisto" <ju...@ko...> wrote: > Albert Lash wrote: >> Are you feeling confident about the documentation I've updated? I just added >> a bit about the password recovery Q&A. If so, let's release version 3.1 to >> sourceforge.net. > > Actually, I haven't had a chance, things suddenly got hectic here. > Hopefully I'll be able to review it this week. > Not to worry. I've just been doing a lot of programming lately. >> I'm still researching the xml sitemaps. I definitely do not want to >> re-invent the wheel. > > Yes, that is a great idea. The biggest thing that I wanted to look at is > if someone is going to use an xml site map for PSA, then it should be in > a form that could be useful un dynamically generating a site map page > for their visitors as well. I don't know what formats are out there now > doing this, but if we can base it off one of those with minor changes, > that would likely be best. Also, see my concerns about structure and xml > file updating. That's exactly right. The plan is that it will be able do a whole lot more that that! Nexista is the best one but the developer is MIA right now. My main concern is that I don't know much about XML transformation. In the mean time I'll work on the XML structure, how to transform it, and how to cache it. > I am trying to get to work on this thing, but I just don't have the time > right now, sorry. No sweat. |
|
From: Justin K. <ju...@ko...> - 2003-06-05 16:33:44
|
Albert Lash wrote: > Are you feeling confident about the documentation I've updated? I just added > a bit about the password recovery Q&A. If so, let's release version 3.1 to > sourceforge.net. Actually, I haven't had a chance, things suddenly got hectic here. Hopefully I'll be able to review it this week. > I'm still researching the xml sitemaps. I definitely do not want to > re-invent the wheel. Yes, that is a great idea. The biggest thing that I wanted to look at is if someone is going to use an xml site map for PSA, then it should be in a form that could be useful un dynamically generating a site map page for their visitors as well. I don't know what formats are out there now doing this, but if we can base it off one of those with minor changes, that would likely be best. Also, see my concerns about structure and xml file updating. I am trying to get to work on this thing, but I just don't have the time right now, sorry. |
