[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