[fw-general] Many modules (10+) versus performance
Hi, I'm thinking about an app with with quite a few modules (10+) and I am a little "theoretically" worried about the potential performance issues related with it. My plan is to: - use extremely few _init* methods in the application Bootstrap class - use none _init* methods in the module's Bootstrap classes - I still want to use Bootstrap classes and manually initialize things as needed via custom methods So, to my knowledge, those worries eventually come down to the: a) Front controller's filesystem module directories discovery b) Bootstrap class file_exists check in Zend_Application_Resource_Modules per each module... Am I right here? Am I not overseeing anything else? Do you consider those worries legitimate? And, finally, is it a good idea with that many modules or would design it differently (as separate apps for example). Thanks very much for your thoughts... m.
Re: [fw-general] Session db save handler discussion
Hello Christian,
> Debugging. With the database, all your sessions for that one
> application are in one place. You can see if for example you made a
> mistake and it just accumulates sessions like crazy. Also you can
> easier get access to the data and then analyze whats happening.
As soon as I am setting different session save path per application I
guess I'm playing the same game. Or am I not?
> Security. Your sessions are yours, not shared with potentially other
> users on the very same box that might "guess" your session id. Highly
> unlikely, but theoretically possible. It's less likely if your
> database is properly secured.
I'm not sure I understand. Are you talking about filesystem security
("...other users on the same box...")?
Thanks,
M.
> Thats my 2c
>
> Greetings,
> Christian Riesen
>
> On Fri, Nov 12, 2010 at 11:44 AM, Marian Meres wrote:
>> Hi,
>>
>> this is not really ZF related, but I hope you don't mind more generic
>> question.
>>
>> I've never used any other session save handler than the native php
>> one. As far as I know it raises concerns only related to a) the disk
>> read/write security and/or b) potential load balancing problems (sync
>> between servers and session save paths). I am OK with those.
>> Application issues such as "number of active users" are no problem as
>> well. I would guess the native one is also more performant (perhaps
>> not true if there are "thousands+" of active sessions).
>>
>> Are you aware of anything else I should take into account?
>>
>> Thanks in advance.
>>
>> m.
>>
>
[fw-general] Session db save handler discussion
Hi, this is not really ZF related, but I hope you don't mind more generic question. I've never used any other session save handler than the native php one. As far as I know it raises concerns only related to a) the disk read/write security and/or b) potential load balancing problems (sync between servers and session save paths). I am OK with those. Application issues such as "number of active users" are no problem as well. I would guess the native one is also more performant (perhaps not true if there are "thousands+" of active sessions). Are you aware of anything else I should take into account? Thanks in advance. m.
Re: [fw-general] MVC design question
If the duplication is isolated to that particular controller only, why
not just simply create a "no action" method to be called in those two
actions... the controller is still just a regular class.
m.
On Sat, Oct 30, 2010 at 12:41 AM, Hector Virgen wrote:
> You can probably place that common code in your preDispatch() hook:
>
> if ($article = $this->_request->getParam('article')) {
> // Load article and assign to view
> }
>
> --
> *Hector Virgen*
> Sr. Web Developer
> http://www.virgentech.com
>
>
>
> On Fri, Oct 29, 2010 at 3:32 PM, debussy007 wrote:
>
>>
>> Hi,
>>
>> That's a recurring problem I have had for a long time :
>>
>> Let's say I have an action allowing to view an article, and an action
>> allowing to edit an article.
>>
>> To setup the views, the code is the same for both actions (get the article
>> id from GET parameter, fetch article, execute some checks, and other
>> things). Only the view files are different, in the edit version, there is a
>> form with input elements.
>>
>> I have here duplicated code. How would you handle this ?
>>
>> Thank you for any advice
>> --
>> View this message in context:
>> http://zend-framework-community.634137.n4.nabble.com/MVC-design-question-tp3019840p3019840.html
>> Sent from the Zend Framework mailing list archive at Nabble.com.
>>
>
[fw-general] Re: Zend_Mail (encoding) problem?
Quick update: surprisingly, I found a bug on my end.
For anyone interested: I was getting and manipulating body text (via
$mail->getBodyText(true)) which I didn't realized was already encoded. So it
ended up being encoded twice.
Cheers,
m.
On Thu, Oct 14, 2010 at 5:12 PM, Marian Meres wrote:
> Hello Everybody,
>
> I have run into two strange problems using Zend_Mail (UTF-8) over SMTP
> transport. Both look like obvious bugs which seems quite unlikely...
>
> ---> First one:
>
> $mail = new Zend_Mail('UTF-8');
> $mail->setBodyText("Příliš žluťoučký kůň úpěl ďábelské ódy");
>
> The above email is received like this:
>
>Content-Type: text/plain; charset=UTF-8
>Content-Transfer-Encoding: quoted-printable
>Content-Disposition: inline
>MIME-Version: 1.0
>
>P=3DC5=3D99=3DC3=3DADli=3DC5=3DA1
> =3DC5=3DBElu=3DC5=3DA5ou=3DC4=3D8Dk=3D=
>C3=3DBD k=3DC5=3DAF=3DC5=3D88 =3DC3=3DBA=3D=0Ap=3DC4=3D9Bl
> =3DC4=3D8F=3D=
>C3=3DA1belsk=3DC3=3DA9 =3DC3=3DB3dy
>
> Where the header is defined correctly (utf-8, quoted printable), but the
> body don't seem to be. First, it's slightly different as with using php
> native 'quoted_printable_encode', which I would not consider as a problem by
> itself (different line width/eol settings possibly?), but also gmail thinks
> it's not ok, as I can't read it in gmail...
>
> Is this a Zend_Mime::encodeQuotedPrintable bug?
>
> ---> Second one (explicitly define body as base64):
>
> $mail = new Zend_Mail('UTF-8');
> $mail->setBodyText("Příliš žluťoučký kůň úpěl ďábelské ódy", null,
> Zend_Mime::ENCODING_BASE64);
>
> This one is received like this:
>
>Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
>Content-Disposition: inline
> MIME-Version: 1.0
>
>UMWZw61sacWhIMW+bHXFpW91xI1rw70ga8WvxYggw7pwxJtsIMSPw6FiZWxza8OpIMOzZHk=
> =3D
>
> Where the header is wrong (defined as "quoted-printable" instead of
> expected "base64"). The content seems to be encoded ok, but as it is defined
> as quoted-printable I can't read it again.
>
> Any light in the dark would be highly appreciated, thanks in advance!
>
> M.
>
>
[fw-general] Zend_Mail (encoding) problem?
Hello Everybody,
I have run into two strange problems using Zend_Mail (UTF-8) over SMTP
transport. Both look like obvious bugs which seems quite unlikely...
---> First one:
$mail = new Zend_Mail('UTF-8');
$mail->setBodyText("Příliš žluťoučký kůň úpěl ďábelské ódy");
The above email is received like this:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
MIME-Version: 1.0
P=3DC5=3D99=3DC3=3DADli=3DC5=3DA1 =3DC5=3DBElu=3DC5=3DA5ou=3DC4=3D8Dk=3D=
C3=3DBD k=3DC5=3DAF=3DC5=3D88 =3DC3=3DBA=3D=0Ap=3DC4=3D9Bl =3DC4=3D8F=3D=
C3=3DA1belsk=3DC3=3DA9 =3DC3=3DB3dy
Where the header is defined correctly (utf-8, quoted printable), but the
body don't seem to be. First, it's slightly different as with using php
native 'quoted_printable_encode', which I would not consider as a problem by
itself (different line width/eol settings possibly?), but also gmail thinks
it's not ok, as I can't read it in gmail...
Is this a Zend_Mime::encodeQuotedPrintable bug?
---> Second one (explicitly define body as base64):
$mail = new Zend_Mail('UTF-8');
$mail->setBodyText("Příliš žluťoučký kůň úpěl ďábelské ódy", null,
Zend_Mime::ENCODING_BASE64);
This one is received like this:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
MIME-Version: 1.0
UMWZw61sacWhIMW+bHXFpW91xI1rw70ga8WvxYggw7pwxJtsIMSPw6FiZWxza8OpIMOzZHk=
=3D
Where the header is wrong (defined as "quoted-printable" instead of expected
"base64"). The content seems to be encoded ok, but as it is defined as
quoted-printable I can't read it again.
Any light in the dark would be highly appreciated, thanks in advance!
M.
Re: [fw-general] Zend_Validate_CreditCard and Authorize.Net's Sandbox API
For others interested, below should be a more complete list of testing
cc numbers for various providers:
$_ccNums = array(
// american express
'ae' => array('378282246310005', '371449635398431'),
// american express corporate
'aec' => array('378734493671000'),
// diners club
'dc' => array('30569309025904', '3852023237'),
// discover
'dcv' => array('6017', '6011000990139424'),
// jcb
'jcb' => array('35301110', '3566002020360505'),
// Master Card
'mc' => array('', '5105105105105100'),
// Visa
'visa' => array('4111', '40121881', '4'),
);
Regards,
M.
On Thu, Apr 29, 2010 at 12:09 AM, Bradley Holt
wrote:
> On Wed, Apr 28, 2010 at 5:41 PM, Rob Riggen wrote:
>>
>> DISCLAIMER: my advice is not necessarily relevant to
>> Zend_Validate_CrediCard.
>> There's a universal test CC num of - not sure if that is
>> going to work in your case but technically that should validate...
>> I think it is a visa, though...
>
> Thanks, Rob! That "universal" test credit card number seemed to make both
> Zend_Validate_CreditCard and Authorize.Net's sandbox API happy. I hope it
> wasn't your credit card number ;-)
>
>>
>> Rob
>>
>> On Wed, Apr 28, 2010 at 5:29 PM, Bradley Holt
>> wrote:
>>>
>>> Has anyone else tried to use Zend_Validate_CreditCard with
>>> Authorize.Net's sandbox API? I've run into a problem that is making it
>>> difficult for me to test my application. The test credit card number that
>>> Authorize.Net provides for their sandbox API (4) is not a valid
>>> credit card number--at least according to Zend_Validate_CreditCard. It
>>> appears that Zend_Validate_CreditCard thinks this is a Visa credit card
>>> (since it starts with a '4') and that Visa credit cards should have a length
>>> of 16 characters but Authorize.Net's test credit card has a length of 13
>>> characters, causing it to fail validation. Has anyone either found other,
>>> valid, test credit numbers that work in Authorize.Net's sandbox API or found
>>> a simple way to get Zend_Validate_CreditCard to accept this as a valid
>>> credit card (at least in testing)?
>>>
>>> --
>>> Bradley Holt
>>> bradley.h...@foundline.com
>>>
>>
>
>
>
> --
> Bradley Holt
> bradley.h...@foundline.com
>
>
Re: [fw-general] Zend_Test_PHPUnit_ControllerTestCase: asserting a checkbox is checked
I confirm I had similar problems with css selectors. I didn't discover
it deeply though, but used xpath assertion instead which worked as
expected.
m.
On Tue, Apr 27, 2010 at 11:04 PM, Núria wrote:
> I'm afraid this is a bug. CSS selectors are converted to XPath queries
> before the evaluation, and apparently there is something wrong with that
> conversion.
>
> In this case, the expression:
>
> #person_acti...@checked="checked"]
>
> is transformed to the XPath query:
>
> //*...@id='person_active'][checked="checked"]
>
> The problem here is that the @ before the attribute checked is missing,
> therefore it fails to match any element.
>
> This workaround will get the job done (although it's not a valid selector):
>
> $this->assertQuery('#person_acti...@checked="checked"]');
>
> or you can use the assertXpath() method instead.
>
> --
>
> Núria
>
> 2010/4/27 David Mintz
>>
>> I am having some trouble figuring out the magic words. My response body
>> contains this:
>>
>> > checked="checked" />
>>
>> In the controller test, I when I say
>>
>> $this->assertQuery('#person_active');
>>
>> the assertion succeeds, but
>>
>> $this->assertQuery('#person_active[checked="checked"]');
>>
>> fails with 'Failed asserting node DENOTED BY
>> #person_active[checked="checked"] EXISTS.'
>>
>> After diddling around with several variations, the only thing that works
>> for me is to assert that the containing element contains a checkbox whose
>> "checked" attribute is "checked:"
>>
>> $this->assertQuery('#person_active-element input[checked="checked"]') ;
>>
>> It might be worth noting that the jQuery snippet
>>
>> $('#person_active[checked="checked"]').length == 1
>>
>> typed into the Firebug console evaluates to true. So it looks like my CSS
>> is kosher.
>>
>> Any ideas? Thanks.
>>
>> --
>> Support real health care reform:
>> http://phimg.org/
>>
>> --
>> David Mintz
>> http://davidmintz.org/
>>
>>
>
>
[fw-general] Re: Zend_Test_PHPUnit_ControllerTestCase not throwing response exceptions?
Just an answer to myself: yes, exceptions are not throwing, it is a feature.
@see Zend_Test_PHPUnit_ControllerTestCase::dispatch()
m.
On Tue, Apr 6, 2010 at 5:06 PM, Marian Meres wrote:
> Hello Everyone,
>
> I'm playing with the Zend_Test_PHPUnit_ControllerTestCase and have run
> into a behavior which is somewhat different from what I'm used to with
> "plain" phpunit testing.
>
> This is what I have:
>
> class MyControllerTest extends Zend_Test_PHPUnit_ControllerTestCase
> {
> public function testSome()
> {
> $this->dispatch('/some');
> $this->assertModule('some');
> }
> }
>
> Now if "/some" throws exception all I see is: Failed asserting last
> module used <"default"> was "some"
>
> I would expect notifying me about the thrown exception right away, as
> it took me a while to track it down...
>
> Is this the expected behavior?
>
> Thank you in advance,
> M.
>
[fw-general] Zend_Test_PHPUnit_ControllerTestCase not throwing response exceptions?
Hello Everyone,
I'm playing with the Zend_Test_PHPUnit_ControllerTestCase and have run
into a behavior which is somewhat different from what I'm used to with
"plain" phpunit testing.
This is what I have:
class MyControllerTest extends Zend_Test_PHPUnit_ControllerTestCase
{
public function testSome()
{
$this->dispatch('/some');
$this->assertModule('some');
}
}
Now if "/some" throws exception all I see is: Failed asserting last
module used <"default"> was "some"
I would expect notifying me about the thrown exception right away, as
it took me a while to track it down...
Is this the expected behavior?
Thank you in advance,
M.
Re: [fw-general] Remember me Zend_Auth cookie
You may find this usefull: http://jaspan.com/improved_persistent_login_cookie_best_practice On Fri, Mar 26, 2010 at 2:50 PM, umpirsky wrote: > > I'm thinking, how to implement remember me in cookie zend style. I'm using > Zend_Auth with Db_Table adapter. > > Maybe we can contribute some component for this. I heard that Cake PHP > already have one. > > Regards, > Saša Stamenković. > -- > View this message in context: > http://n4.nabble.com/Remember-me-Zend-Auth-cookie-tp1692215p1692215.html > Sent from the Zend Framework mailing list archive at Nabble.com. >
[fw-general] HTTP response code when not logged in
Hello everyone, what kind of HTTP response codes would you suggest using when accessing a page which requires user to be logged in and there is no current identity present? Initially I thought about "401 Unauthorized", but the definition says: "The response MUST include a WWW-Authenticate header field containing a challenge applicable to the requested resource" where I'm not sure I know what that means... I also thought about "403 Forbidden", but again from the definition: "Authorization will not help and the request SHOULD NOT be repeated" does not look like a good choice. Or forget it and stick with good old "200 OK"? Thanks, M.
Re: [fw-general] Best practice to share identity map across mappers? Static registry?
Hello Hector,
> Is there a reason you don't want to go with a static identity map?
Well, I consider usage of static map in this case most simple and even correct.
But as I'm in the planning phase and always questioning the design, I
want to make sure I'm doing it the correct way. And after reading many
posts on this topic recently from people I consider much more
experienced (among others mainly Matthew's), it looks like trying to
avoid the static registry usage may be worth the energy. Perhaps even
if I am unable to clearly see the reasons (other than testing)...
Thanks.
M.
Some notes here: http://misko.hevery.com/code-reviewers-guide/
On Mon, Aug 31, 2009 at 6:34 AM, Hector Virgen wrote:
>
> Marian,
> A static identity map is the way to go. Page 291 of Php objects, patterns,
> and practice by Matt Zandstra demonstrates how to build a simple but
> effective identity map. Is there a reason you don't want to go with a static
> identity map?
> --
> Hector
>
>
> On Sun, Aug 30, 2009 at 10:32 AM, Marian Meres wrote:
>>
>> Hello Benjamin,
>>
>> thank you... but either I can't follow, or I must not have described
>> properly the question. Because I do not understand how the factory could
>> help you to share the map, unless you do not share the factory then...
>>
>> Example:
>>
>> class MapperFactory
>> {
>> protected $_identityMap;
>> public function create($name)
>> {
>> $mapperClass = $this->_somePrefix . $name;
>> $mapper = new $mapperClass();
>> $mapper->setIdentityMap($this->getIdentityMap($name));
>> return $mapper;
>> }
>> }
>>
>> // somewhere in log on (user service)
>> $mapperFactory = new MapperFactory();
>> $userMapper = $mapperFactory->create('user');
>> $user = $userMapper->find(1); // find also saves the user identity.
>>
>> // somewhere in article model
>> class Article
>> {
>> // lazy load author
>> public function getAuthor()
>> {
>> if (null == $this->_author) {
>> $mapperFactory = new MapperFactory();
>> $userMapper = $mapperFactory->create('user');
>> $this->_author = $userMapper->find($this->_authorId);
>> }
>> return $this->_author;
>> }
>> }
>>
>> My question is, how to design the whole thing so that the later model can
>> reuse the identity set in the log on service (if applicable), while trying
>> to avoid implementing static something somewhere. My understanding is, that
>> without introducing new "domain superlayer" this could hardly be done, but
>> is it worth it then? Why just not live with the static, with proper
>> resetings (I know the test issues).
>>
>> Zend_Application is nice example where it works well (the good, non static
>> container), but is this approach applicable to pure domain classes, where
>> there is no front controller to pull the container from?
>>
>> Thank you again.
>>
>> And, BTW, respect for the Zend_Entity work! Very inspiring.
>>
>> Regards,
>> M.
>>
>>
>> On Sun, Aug 30, 2009 at 5:17 PM, Benjamin Eberlei wrote:
>> > hello,
>> >
>> > If you dont instantiate your mappers through a factory you probably will
>> > have
>> > lots of work to do if you dont make access to the identity map global via a
>> > static method.
>> >
>> > greetings,
>> > Benjamin
>> >
>> > On Sunday 30 August 2009 04:58:32 pm Marian Meres wrote:
>> >> Hi All,
>> >>
>> >> I have many domain models where each has its own data mapper. These
>> >> mappers are spread across many places as a) services use mappers, b)
>> >> mapper x uses mapper y, c) and even models use mappers (only in the
>> >> case of lazy loading).
>> >>
>> >> I want mappers to utilize the identity map pattern (which is itself
>> >> pretty straightforward). I guess the whole pattern makes more sense
>> >> when used as a shared map across the mappers rather than for each to
>> >> have its own.
>> >>
>> >> Since the mappers usage (and instantiation) is wide spread (at least
>> >> in my case), the only solution I could think of is always a sort of a
>> >> static one (either through static members, or static "managers", or
>> >> even some injectable containers which default to static
>> >> Zend_Registry).
>> >>
>> >> What would you suggest, other than the static way?
>> >>
>> >> Thank you in advance.
>> >>
>> >> M.
>> >
>> >
>> > --
>> > Benjamin Eberlei
>> > http://www.beberlei.de
>> >
>>
>
Re: [fw-general] Best practice to share identity map across mappers? Static registry?
Hello Benjamin,
thank you... but either I can't follow, or I must not have described
properly the question. Because I do not understand how the factory could
help you to share the map, unless you do not share the factory then...
Example:
class MapperFactory
{
protected $_identityMap;
public function create($name)
{
$mapperClass = $this->_somePrefix . $name;
$mapper = new $mapperClass();
$mapper->setIdentityMap($this->getIdentityMap($name));
return $mapper;
}
}
// somewhere in log on (user service)
$mapperFactory = new MapperFactory();
$userMapper = $mapperFactory->create('user');
$user = $userMapper->find(1); // find also saves the user identity.
// somewhere in article model
class Article
{
// lazy load author
public function getAuthor()
{
if (null == $this->_author) {
$mapperFactory = new MapperFactory();
$userMapper = $mapperFactory->create('user');
$this->_author = $userMapper->find($this->_authorId);
}
return $this->_author;
}
}
My question is, how to design the whole thing so that the later model can
reuse the identity set in the log on service (if applicable), while trying
to avoid implementing static something somewhere. My understanding is, that
without introducing new "domain superlayer" this could hardly be done, but
is it worth it then? Why just not live with the static, with proper
resetings (I know the test issues).
Zend_Application is nice example where it works well (the good, non static
container), but is this approach applicable to pure domain classes, where
there is no front controller to pull the container from?
Thank you again.
And, BTW, respect for the Zend_Entity work! Very inspiring.
Regards,
M.
On Sun, Aug 30, 2009 at 5:17 PM, Benjamin Eberlei
wrote:
> hello,
>
> If you dont instantiate your mappers through a factory you probably will
have
> lots of work to do if you dont make access to the identity map global via
a
> static method.
>
> greetings,
> Benjamin
>
> On Sunday 30 August 2009 04:58:32 pm Marian Meres wrote:
>> Hi All,
>>
>> I have many domain models where each has its own data mapper. These
>> mappers are spread across many places as a) services use mappers, b)
>> mapper x uses mapper y, c) and even models use mappers (only in the
>> case of lazy loading).
>>
>> I want mappers to utilize the identity map pattern (which is itself
>> pretty straightforward). I guess the whole pattern makes more sense
>> when used as a shared map across the mappers rather than for each to
>> have its own.
>>
>> Since the mappers usage (and instantiation) is wide spread (at least
>> in my case), the only solution I could think of is always a sort of a
>> static one (either through static members, or static "managers", or
>> even some injectable containers which default to static
>> Zend_Registry).
>>
>> What would you suggest, other than the static way?
>>
>> Thank you in advance.
>>
>> M.
>
>
> --
> Benjamin Eberlei
> http://www.beberlei.de
>
[fw-general] Best practice to share identity map across mappers? Static registry?
Hi All, I have many domain models where each has its own data mapper. These mappers are spread across many places as a) services use mappers, b) mapper x uses mapper y, c) and even models use mappers (only in the case of lazy loading). I want mappers to utilize the identity map pattern (which is itself pretty straightforward). I guess the whole pattern makes more sense when used as a shared map across the mappers rather than for each to have its own. Since the mappers usage (and instantiation) is wide spread (at least in my case), the only solution I could think of is always a sort of a static one (either through static members, or static "managers", or even some injectable containers which default to static Zend_Registry). What would you suggest, other than the static way? Thank you in advance. M.
Re: [fw-general] XSS Prevention with Zend Framework
Hello,
I guess Ondrej was just pointing out, that escaping itself is a little
bit more complex than just htmlspecialchars-ing the data. And
*automaticaly impossible* with default ZF view design (phtml
templates) in a meaning that it still requires human to change the
escaping method based on the context (html, js, css, xml...)
Regards,
Marian
P.S.: ahoj ondrej
On Tue, Jul 14, 2009 at 1:50 PM, Pádraic Brady wrote:
> PHP's magic_quotes was a mistake because it failed to do anything useful and
> instead created more problems that lead to greater insecurity and
> uncertainty instead. Automatic escaping with ZF 2.0 is anything but - it is
> a simple concept whereby html escaping is applied by default to any request
> for a view variable (one can assume most views are HTML). If you wish not to
> have this escaping applied, there will be a similar method for retrieving
> the raw value of any variable (then you can do the XML/JSON thing).
>
> The security principle involved is "never trust a human" ;). People forget
> to manually escape variables - especially when escaping has it's own method
> which is tortuous to use everywhere on everything it's needed on - it also
> looks ugly cluttering up my view templates. All you need is someone to get
> lazy or forget to use it and the application is thrown into risk. Then you
> have the smarties who like to use it only where they believe it's necessary
> - a silly presumption since any change could make put any view variable into
> a scope where escaping is essential. The ZF 2.0 default behaviour is
> therefore a poka-yoke (from Japanese - refers to any system in a process
> which helps an operator avoid mistakes due to human error). Since we can't
> trust humans - we won't. We'll escape everything and then if you want
> unescaped values you will need to use an obvious "raw" retrieval method
> which can be spotted by anyone, requires deliberate action to use, and can
> be double-checked by peers.
>
> How is that even remotely like the magic_quotes problem?
>
> Pádraic Brady
>
> http://blog.astrumfutura.com
> http://www.survivethedeepend.com
> OpenID Europe Foundation Irish Representative
>
>
>
> From: Ondrej Ivanič
> To: fw-general@lists.zend.com
> Sent: Tuesday, July 14, 2009 6:47:19 AM
> Subject: Re: [fw-general] XSS Prevention with Zend Framework
>
> Hi
>
>> fixing that...), but I will note: Starting with 2.0, escaping will be
>> the default when retrieving variables from the view object, and you will
>> need to request the raw value explicitly if you need it. This is a
>
> Thats sounds like a ZF version of magic_quotes... How do you want to
> deal with different escaping in javascript, css, html, xml? View
> script could be mix of anything i.e:
>
> var = '1/2"' ?>
> $this->var; ?>
>
>
> document.title = "var; ?>"
>
>
> and the correct output is:
>
> 1/2"
>
> document.title = "1\/2\"";
>
>
> For a proper automatic escaping you need an information about context
> which is very hard (impossible) to get now...
>
> html: htmlspecialchars($s, ENT_QUOTES)
> xml: htmlspecialchars(preg_replace('#[\x00-\x08\x0B\x0C\x0E-\x1F]+#',
> '', $s), ENT_QUOTES)
> css: addcslashes($s, "\x00..\x2C./:;<=>?...@[\\]^`{|}~")
> ccs inside html attributes: htmlspecialchars(addcslashes($s,
> "\x00..\x2C./:;<=>?...@[\\]^`{|}~"), ENT_QUOTES)
> javascript: json_encode($s)
> js inside html attributes: htmlspecialchars(json_encode($s), ENT_QUOTES);
>
> --
> Ondrej Ivanic
> (ondrej.iva...@gmail.com)
>
Re: [fw-general] setFallbackAutoloader(true) causing module boostraps not load
Hello Matthew, On Fri, Jun 19, 2009 at 7:41 PM, Matthew Weier O'Phinney wrote: > -- Marian Meres wrote > (on Friday, 19 June 2009, 05:28 PM +0200): >> I ran into one issue with the setFallbackAutoloader(true). I have >> modular app with usual directory structure (via Zend_Tool), with >> module "test". Test_Boostrap class is located as usual in >> modules/test/Bootstrap.php. Works perfect. >> >> But with the fallbackAutoloader enabled (snippets from index.php): >> >> Zend_Loader_Autoloader::getInstance()->setFallbackAutoloader(true); >> $application->bootstrap()->run(); >> >> I get include warnings ...Failed opening 'Test\Bootstrap.php'..., while this: >> >> $application->bootstrap(); >> Zend_Loader_Autoloader::getInstance()->setFallbackAutoloader(true); >> $application->run(); >> >> works fine. >> >> Is that the correct behaviour? > > I believe this may be fixed already in trunk -- can you test, please? Just partialy - I'm not getting warnings for the "Failed opening 'Test\Bootstrap.php'" anymore, but still "Failed opening 'FrontController.php'" (I didn't mention that before). Tested with revision 16169. Regards, M.
[fw-general] setFallbackAutoloader(true) causing module boostraps not load
Hi, I ran into one issue with the setFallbackAutoloader(true). I have modular app with usual directory structure (via Zend_Tool), with module "test". Test_Boostrap class is located as usual in modules/test/Bootstrap.php. Works perfect. But with the fallbackAutoloader enabled (snippets from index.php): Zend_Loader_Autoloader::getInstance()->setFallbackAutoloader(true); $application->bootstrap()->run(); I get include warnings ...Failed opening 'Test\Bootstrap.php'..., while this: $application->bootstrap(); Zend_Loader_Autoloader::getInstance()->setFallbackAutoloader(true); $application->run(); works fine. Is that the correct behaviour? Thanks in advance for your time. Regards, M.
[fw-general] Zend_File_Transfer question (concurrent uploads)
Hi Everyone, I'm working on interface where users can upload basically any kind of attachment file. I was playing with the Zend_File_Transfer where I'm using one generic temp dir (via setDestination) to upload and once everything's valid I'm renaming the uploaded file to the proper dir. So far everything ok. What I'm concerned about is that I think I have no control on multiple concurrent uploads via different users. In other words, what if the uploading original file name is the same among multiple users? AFAIK PHP natively solves this issue with giving each uploaded file a unique name ($_FILES['tmp_name']) where I don't have to worry. Is this issue somehow handled in Zend_File? If not, what would you suggest as best practice to avoid such conflicts? Or am I overseeing something? I know I can always create a unique temp dir, but that doesn't feel right... Thanks in advance. Regards, Marian
