[pLog-svn] r6088 - plog/branches/lifetype-1.2/class/security

Andy myside at myside.mine.nu
Wed Jan 2 14:32:34 EST 2008



On Wed, 2 Jan 2008, Jon Daley wrote:

> On Wed, 2 Jan 2008, Andy wrote:
>> I am concerned mostly with the API.  Using a public class that depends on
>> a new method with-in new class, or changes to object structures that are
>> returned.
>>
>> Could their be a version that could set the standard for structor, yet
>> build on the API, keeping legacy systems usable?  This would be a project
>> within itself, but would version 3 be a consideration for this?  Will 2.5
>> objects be obtained with the same method and class data returned as a
>> stable, and as usable in a production system, that a legacy 2.X would
>> have?
> 	Don't we already follow that model?  There are a number of
> functions that are deprecated according to the documentation, but still
> exist for years after release.

I am mostly concerned with the major 2.x.x releases.  If a security hole 
were to be detected, and a major code change would have to be provisioned 
for the API - can you assure me that the references to object data 
requests would not be altered?

My last concern is with new feature sets in which the current API I 
am using would not support, and additions would be made.  How would
these new features be set at default, in a production system, with
the new version, without disrupting the secure and effecient 
execution of the previous release, in addition to the above?

Could their be a seperation of code features based on version releases, 
yet still be available in the new applications provided?

If this is so, dis-regard my original message, and all the love to you. 
:)

>
>> I have no Lifetype PHP custom code.  I use you API in it's entirety.
> 	Good.  I wouldn't expect any problems when upgrading between minor
> releases.  Have you had trouble before, or just fearing the worst?
>
>> I am considering making a single change in ragards to seperate user
>> dependant tables in DB's, while mainting a private admin SQL database.
>> However, this is too minor of a source code change to be worried about
>> when considering upgrading versions.
> 	I'd direct you towards writing your own userdata integration
> class, and not touch any of the core code.  Then you can use whatever
> tables you want.
> _______________________________________________
> pLog-svn mailing list
> pLog-svn at devel.lifetype.net
> http://limedaley.com/mailman/listinfo/plog-svn
>


More information about the pLog-svn mailing list