Hi Stats,
2012/1/20 Stas Malyshev <smalys...@sugarcrm.com>: > Hi! > > >> Hi Stats, >> >> Ok, I'll hold committing to 5.4, but commit it only to trunk. >> >> Any comments form anyone? for committing to trunk? >> Patch details and user land counter measure are in RFC. > > > Re-reading the discussion, I see that the question of why we need separate > validator handler is still unresolved. I think we were left with this: It's for reduced complexity. With separate validation function, we can - reduce PS module writer's choice whether validation belong to PS_OPEN_FUNC() or PS_READ_FUNC() session data. Validation always belongs to PS_VALIDATE_SID_FUNC(). - inform user save handler (PHP script save handler) writers that they are responsible to validate session ID. We can make new session ID in PS_OPEN_FUNC() or PS_READ_FUNC() always when ID is not already initialized one, by calling private validation function from PS_OPEN_FUNC() or PS_READ_FUNC(). However, I think it's more cleaner to keep PS module's modular architecture. Current session module's code is complex enough. Not many people would understand the logic at a glance. New PS module writers should always write SID validation function. Separate API is easier for most people, I suppose. However, if you insist, I'm ok to modify patch so that it validates session ID in PS_READ_FUNC(). > > >> In this case, users cannot distinguish whether PS module is adoptive or >> not. > > > But this can be solved by documentation, unless you mean "users in the code" > - but then I don't see how having new handler would help as PHP code can not > really check for this handler, can it? So the question why we need such > handler is still open. > However if we would have binary compatible patch it probably would be ok for > 5.4.1. Choice is yours. If it's ok to add structure members that requires current patch, I'll commit new module structure now. And I'll commit the rest for 5.4.1. If you prefer to maintain current structure/API, I'll modify patch. I would like to add strict session to PHP 5.3, so I have to do that anyway for binary compatibility. Regards, -- Yasuo Ohgaki -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
