Re: [fw-general] PDO::prepare cannot find an existing table.
Hi, the table name is case-sensitive now. for e.g. the table name in mysql db was USERS, while I tried it as users. I got the same error as yours. Waigani wrote: I've got same problem.Using ZF 1.03, trying to connect to mysql table: Zend_Db_Statement_Exception' with message 'SQLSTATE[42S02]: Base table or view not found: 1146 Jared Smith wrote: I just migrated to Zend Framework 0.6.0 from a lower version. Code which was previously working is now generating this error: Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE[42S02]: Base table or view not found: 1146 Table 'eca.part' doesn't exist' in /var/www/localhost/htdocs/echo/library/Zend/Db/Adapter/Pdo/Abstract.php:119 The table DOES exist, and I can query it fine from mysql command line. It looks like a PDO::prepare error, for that is what is happening on line 119, simply a call to _connection-prepare($sql). The SQL statement is a vanilla SELECT with no joins, from a single table. This error comes up with every SELECT query I run on any table. Does anyone recognize this problem? -Jared -- View this message in context: http://www.nabble.com/PDO%3A%3Aprepare-cannot-find-an-existing-table.-tp8282801p16323990.html Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] quoteOutOf?
Hello, This post just gets me more confused, because I'm using $db-quote() in almost all my inserts, but when I get the data back, all my carriage returns are converted to \n\r and single quotes become \'. I also used PHP's stripslashes() but has no effect on carriage returns. Is there an effective way to unquote results that where inserted using quote() ? Thanks! Mauricio Matthew Ratzloff wrote: Hi Jared, I'm just now learning all the intricacies of preventing SQL injection attacks. I understand the value of using Zend_Db quoting for values that can be manipulated by users.. what I can't find, though, is a good unescape command. If I have an article, for example, that I want to store and then retrieve and display, I'll quote the article before insertign it. This will, ofcourse, escape all quotes, but it will also put a set of single quotes around my entire article. When I then retrieve the article and run stripslashes() to unescape the quotes, it leaves the surrounding single quotes. Looking at your example, I think you may be a little confused. Escaping certain characters in preparation for use in an SQL statement simply inserts the values as intended to be read by the end user into the database. There's no need to unescape them following a SELECT statement because no escape characters are stored in the database record. For anyone else that's curious--without escaping, someone might enter the following: Username: admin Password: ' OR '1' = '1 If it's not properly filtered, it could break out of the AND Password = '(password)' portion of the WHERE clause and return admin without properly authenticating them. Hope that helps, -Matt -- View this message in context: http://www.nabble.com/quoteOutOf--tp6416052p16324521.html Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] quoteOutOf?
-- Mauricio Cuenca [EMAIL PROTECTED] wrote (on Thursday, 27 March 2008, 05:20 AM -0700): This post just gets me more confused, because I'm using $db-quote() in almost all my inserts, but when I get the data back, all my carriage returns are converted to \n\r The above is likely something to do with your database or with the input provided, not with Zend_Db. and single quotes become \'. I also used PHP's stripslashes() but has no effect on carriage returns. My guess is that you have magic_quotes_gpc on, so data is getting into the database with quotes escaped. Please make sure this setting is off. Zend_Db_Adapter::quote() itself will only escape quotes for insertion; when you get them back from the database, they will not be quoted. What *can* happen, however, is double escaping, which typically happens when you have magic_quotes_gpc on *and* use a tool such as Zend_Db_Adapter::quote(); this leads to the exact situation you've described. Is there an effective way to unquote results that where inserted using quote() ? Thanks! Mauricio Matthew Ratzloff wrote: Hi Jared, I'm just now learning all the intricacies of preventing SQL injection attacks. I understand the value of using Zend_Db quoting for values that can be manipulated by users.. what I can't find, though, is a good unescape command. If I have an article, for example, that I want to store and then retrieve and display, I'll quote the article before insertign it. This will, ofcourse, escape all quotes, but it will also put a set of single quotes around my entire article. When I then retrieve the article and run stripslashes() to unescape the quotes, it leaves the surrounding single quotes. Looking at your example, I think you may be a little confused. Escaping certain characters in preparation for use in an SQL statement simply inserts the values as intended to be read by the end user into the database. There's no need to unescape them following a SELECT statement because no escape characters are stored in the database record. For anyone else that's curious--without escaping, someone might enter the following: Username: admin Password: ' OR '1' = '1 If it's not properly filtered, it could break out of the AND Password = '(password)' portion of the WHERE clause and return admin without properly authenticating them. Hope that helps, -Matt -- View this message in context: http://www.nabble.com/quoteOutOf--tp6416052p16324521.html Sent from the Zend Framework mailing list archive at Nabble.com. -- Matthew Weier O'Phinney PHP Developer| [EMAIL PROTECTED] Zend - The PHP Company | http://www.zend.com/
[fw-general] ZF bc break with php 5.2.6
Hi,
with the upcomming next release of php one bug feature will change.
http://news.php.net/php.internals/36606
any own extended version of a single pattern class that is based on the same
mechanism like the Zend_Controller_Front
class My_Controller_Front extends Zend_Controller_Front
{
public static function getInstance()
{
if (null === self::$_instance) {
self::$_instance = new self();
}
return self::$_instance;
}
}
And the Zend_Controller_Front __construct is private will raise with 5.2.6 a
fatal error. This mease the contructor should be protected to keep it
working with 5.2.6.
Can anyone confirm this ?
-- Marco Kaiser
Re: [fw-general] Zend_Form
-- SiCo007 [EMAIL PROTECTED] wrote
(on Thursday, 27 March 2008, 05:45 AM -0700):
I've just started to actually implement Zend Form, so far it's going well but
it seems far too difficult (read over the top) to actually make changes to
the way the form is displayed.
Maybe I'm not understanding the documentation properly, but is it possible
to remove all the default decorators from the form ($form = new
Zend_Form(array('disableLoadDefaultDecorators' = true));) Only seems to
remove the default form decorators? I want groups and elements stripped too?
I've done it so far by handling the elements, then the groups, then specific
submit button, cancel button and hidden elements, in my opinion I want
something clean which I can then put my own code on to without having to
disable everything first! (I do realise everyone is different, it just
appears the ZF is focusing on trying to do everything, rather than forcing
the developer to get their hands dirty!).
The disableLoadDefaultDecorators setting is per object; you need to
specify it for each form, group, sub form, and element separately. (For
the most part, we try not to have the form object communicate global
preferences to the items it contains).
It sounds to me like you might want a setting to of
'disableAllDefaultDecorators' that could be applied to the form and
propagate to all items created with the form; if so, please place a
request in the tracker.
Note, however, that you can specify the decorators you want *during*
configuration, and this will override the defaults (the defaults won't
even be loaded).
Is there a way to change the decorators on all buttons, or all text boxes?
Yes: it's called extension. :-)
Create your own extensions of these classes and specify the decorators
you want in your subclasses (best way is by overriding the
loadDefaultDecorators() method). Then simply provide a prefixPath for
elements to the form object, and your custom elements will be utilized.
This is the best way to approach a situation where you know you will not
be using the shipped defaults.
Zend Framework classes are built to be extended; that's what OOP is all
about. In a component such as Zend_Form, it's the recommended way of
customizing it to suit your needs. Yes, there are many facilities for
customizing the rendering, but to make the customized rendering
re-usable, the easiest way is to extend the various classes and modify
them for your needs. Each component in Zend_Form has a section on
customization that you can use as a guide.
Is it possible, if I develop a concrete layout decorator to render
everything, based on the example in the manual (although I can't for the
life of me find the example now), to tell the type of each form element and
change the rendering?
Again, you should probably create your own custom elements, as it's the
cleanest approach.
There are some examples of creating custom elements in the manual, but
if you need more tips, please let me know.
--
Matthew Weier O'Phinney
PHP Developer| [EMAIL PROTECTED]
Zend - The PHP Company | http://www.zend.com/
Re: [fw-general] ZF bc break with php 5.2.6
-- Marco Kaiser [EMAIL PROTECTED] wrote
(on Thursday, 27 March 2008, 02:14 PM +0100):
Hi,
with the upcomming next release of php one bug feature will change.
http://news.php.net/php.internals/36606
any own extended version of a single pattern class that is based on the same
mechanism like the Zend_Controller_Front
class My_Controller_Front extends Zend_Controller_Front
{
public static function getInstance()
{
if (null === self::$_instance) {
self::$_instance = new self();
}
return self::$_instance;
}
}
And the Zend_Controller_Front __construct is private will raise with 5.2.6 a
fatal error. This mease the contructor should be protected to keep it
working with 5.2.6.
Can anyone confirm this ?
Actually, the constructor was made protected for the 1.5.1. release ;-)
--
Matthew Weier O'Phinney
PHP Developer| [EMAIL PROTECTED]
Zend - The PHP Company | http://www.zend.com/
Re: [fw-general] ZF bc break with php 5.2.6
Hi Matthew,
okay. Someone should also check other singleton implementations in the
framework.
-- Marco
On Thu, Mar 27, 2008 at 2:49 PM, Matthew Weier O'Phinney [EMAIL PROTECTED]
wrote:
-- Marco Kaiser [EMAIL PROTECTED] wrote
(on Thursday, 27 March 2008, 02:14 PM +0100):
Hi,
with the upcomming next release of php one bug feature will change.
http://news.php.net/php.internals/36606
any own extended version of a single pattern class that is based on the
same
mechanism like the Zend_Controller_Front
class My_Controller_Front extends Zend_Controller_Front
{
public static function getInstance()
{
if (null === self::$_instance) {
self::$_instance = new self();
}
return self::$_instance;
}
}
And the Zend_Controller_Front __construct is private will raise with
5.2.6 a
fatal error. This mease the contructor should be protected to keep it
working with 5.2.6.
Can anyone confirm this ?
Actually, the constructor was made protected for the 1.5.1. release ;-)
--
Matthew Weier O'Phinney
PHP Developer| [EMAIL PROTECTED]
Zend - The PHP Company | http://www.zend.com/
--
Marco Kaiser
Re: [fw-general] Zend_Form
Thanks, a further question, what is the preffered way of setting custom validator messages, I couldn't get any of the ways I tried (both setting the message by grabbing the validator, which seems like an extra step, trying to pass the messages in an array in addElement and finally trying to set the message for the alllow empty. Will there be a simple (preferably as part of addElement) or does it already exist and I just haven't found it?! Simon - Simon Corless http://www.ajb007.co.uk/ -- View this message in context: http://www.nabble.com/Zend_Form-tp16324818p16332260.html Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Zend_Form
-- SiCo007 [EMAIL PROTECTED] wrote
(on Thursday, 27 March 2008, 12:50 PM -0700):
Thanks, a further question, what is the preffered way of setting custom
validator messages, I couldn't get any of the ways I tried (both setting the
message by grabbing the validator, which seems like an extra step, trying to
pass the messages in an array in addElement and finally trying to set the
message for the alllow empty.
Will there be a simple (preferably as part of addElement) or does it already
exist and I just haven't found it?!
It's documented and straightforward: You pass an array of error
code/message pairs to the 'messages' key in the params for the
validator:
$element = new Zend_Form_Element(array(
'validators' = array(
array('NotEmpty', false, array(
'messages' = array('isEmpty' = 'This is a custom message')
)),
)
);
The trick is remembering that 'messages' should be an *array*, and that
it should contain key/value pairs of validation class constants/mesages.
You can also simply use translation files, which are the easier method.
In that case, you provide translations for each validation error code
you want a custom message for, and attach the translator:
$form-setTranslator($translate);
You can use a translation object even if you only have one language; the
nice part is it future-proofs your site for additional languages. :-)
--
Matthew Weier O'Phinney
PHP Developer| [EMAIL PROTECTED]
Zend - The PHP Company | http://www.zend.com/
Re: [fw-general] Zend_Form and empty action
See this one: http://www.w3.org/TR/html4/interact/forms.html#adef-action 'User agent behavior for a value other than an HTTP URI is undefined.' Ádám On Thu, Mar 27, 2008 at 2:09 AM, Steve Clay [EMAIL PROTECTED] wrote: Joó Ádám wrote: an empty path is a relative path, and an empty relative path means that the requested URL will be the current one minus the part after the last slash. Then the browser is broken. The empty string is a valid relative URI, and indicates no change from the base URI. Just like a href=reload current URL/a. http://www.w3.org/TR/html4/struct/links.html#h-12.4.1 By default, the base URI is that of the current document So if the form is at /controller/action then an empty action attribute should not cause submission to /controller/ . It's possible that your server is setting the base URI via some extra header. E.g. when you use Apache's MultiViews, the Content-Location header is sent with the full filename, regardless that you requested the file w/o extension. -- Steve Clay http://mrclay.org/
Re: [fw-general] How to get data after calling $this-_forward()
http://framework.zend.com/manual/en/zend.controller.dispatcher.html
The action controller method that controlls such dispatching is _forward();
call this method from any of the pre/postDispatch() or action methods,
providing an action, controller, module, and optionally any additional
parameters you may wish to send to the new action:
public function fooAction()
{
// forward to another action in the current controller and module:
$this-_forward('bar', null, null, array('baz' = 'bogus'));
}
public function barAction()
{
// forward to an action in another controller, FooController::bazAction(),
// in the current module:
$this-_forward('baz', 'foo', null, array('baz' = 'bogus'));
}
On Thu, Mar 27, 2008 at 5:50 PM, mysticav [EMAIL PROTECTED] wrote:
basically I want this:
function fooAction(){
$var = 'test';
$this-_forward('bar');
}
function barAction(){
print $var; // prints 'test'
}
AS you can see, I want to share data from the first action.
Is it possible ?
--
View this message in context:
http://www.nabble.com/How-to-get-data-after-calling-%24this-%3E_forward%28%29-tp16340300p16340300.html
Sent from the Zend Framework mailing list archive at Nabble.com.
[fw-general] Bug in Zend Form - On second bad submit, repopulated values incorrect
I have a Zend_Form class used for a login form. When I validate the form
once, it repopulates correctly. When I resubmit the form a second time with
a bad password value but the correct login value, the login value is
repopulated as 'login'. I'm not quite sure what in tarnation could be
happening here, but maybe someone can give me a hand.
I'm using the latest from:
http://framework.zend.com/svn/framework/branch/release-1.5/library/Zend ...
r9083 as of this writing.
Here's my form class:
1 ?php
2
3 class My_Form_Login extends Zend_Form {
4
5 public function __construct($options = null) {
6 parent::__construct($options);
7
8 $this-setAction('login/login');
9 $this-setMethod('post');
10
11 $login = new Zend_Form_Element_Text('login');
12 $login-setLabel('Login');
13 $login-setRequired(true);
14 $this-addElement($login);
15
16 $pass = new Zend_Form_Element_Password('pass');
17 $pass-setLabel('Password');
18 $pass-setRequired(true);
19 $this-addElement($pass);
20
21 $submit = new Zend_Form_Element_Submit('submit');
22 $submit-setLabel('Submit');
23 $this-addElement($submit);
24
25 }
26
27 }
28
29 ?
And here's the login action:
30 function loginAction() {
31 $form = new My_Form_Login();
32 $param = $this-getRequest()-getParams();
33
34 //Init the view up here, even if we throw it out.
35 $this-initView();
36
37 if(!empty($param['submit']) $form-isValid($param)) {
38 // If the form validated, then we know there are both passwd and
value fields.
39 // Authenticate against the databse. First, get an instance.
40 $auth = Zend_Auth::getInstance();
41
42 // Let's set up the adapter. Don't forget that the password is
just hashed,
43 // while the email has had htmlspecialchars run on it before
being inserted.
44 // This also serves as our input cleaning... no bobby tables!
45 $adapt = new
Zend_Auth_Adapter_DbTable(Zend_Registry::get('db'));
46 $adapt-setTableName('users');
47 $adapt-setIdentityColumn('login');
48 $adapt-setCredentialColumn('sha1password');
49 $adapt-setCredential(sha1($param['pass']));
50 $adapt-setIdentity(htmlspecialchars($param['login']));
51
52
53 // And run the auth.
54 $result = $auth-authenticate($adapt);
55
56 // Compare the values and do stuff.
57 if($result-isValid()) {
58 $storage = new Zend_Auth_Storage_Session();
59
$storage-write($adapt-getResultRowObject(array('login','password_reset')));
60 $auth-setStorage($storage);
61 $this-_redirect('/user/index');
62 } else {
63 $this-view-message = 'Invalid login. Please try again.';
64 $this-view-form = $form;
65 }
66 } else {
67 $this-view-form = $form;
68 }
69 }
And here's the login form:
1 h1Administration Login/h1
2 ? if(!empty($this-message)): ?
3 p class=error?= $this-message ?/p
4 ? endif; ?
5 ?= $this-form ?
6
The behaviour I'm getting can be reproduced in Firefox and Safari by
repeating the following steps:
1) Going to the login form in your browser
2) Typing a username in the login field
3) Typing an incorrect password
4) The form repopulates as expected, and shows the expected error message.
5) Type another incorrect password
6) The form repopulates with the string 'login' in the login instead of the
expected user name.
Matt, I'll email you a link to my working copy so you can see the behaviour.
Thanks!
-Karl
[fw-general] Re: Bug in Zend Form - On second bad submit, repopulated values incorrect
Nevermind, self-help desk strikes again. On the second bad submit, the URL
looks like:
localhost/login/login/login/login
instead of the proper /login/login.
Changing line 8 of the form class to
8 $this-setAction('/login/login');
fixed the problem.
Kids, this is why you shouldn't file bug reports after midnight.
Hope the code example can help someone out!
-K
On Fri, Mar 28, 2008 at 12:34 AM, Karl Katzke [EMAIL PROTECTED] wrote:
I have a Zend_Form class used for a login form. When I validate the form
once, it repopulates correctly. When I resubmit the form a second time with
a bad password value but the correct login value, the login value is
repopulated as 'login'. I'm not quite sure what in tarnation could be
happening here, but maybe someone can give me a hand.
I'm using the latest from:
http://framework.zend.com/svn/framework/branch/release-1.5/library/Zend...
r9083 as of this writing.
Here's my form class:
1 ?php
2
3 class My_Form_Login extends Zend_Form {
4
5 public function __construct($options = null) {
6 parent::__construct($options);
7
8 $this-setAction('login/login');
9 $this-setMethod('post');
10
11 $login = new Zend_Form_Element_Text('login');
12 $login-setLabel('Login');
13 $login-setRequired(true);
14 $this-addElement($login);
15
16 $pass = new Zend_Form_Element_Password('pass');
17 $pass-setLabel('Password');
18 $pass-setRequired(true);
19 $this-addElement($pass);
20
21 $submit = new Zend_Form_Element_Submit('submit');
22 $submit-setLabel('Submit');
23 $this-addElement($submit);
24
25 }
26
27 }
28
29 ?
And here's the login action:
30 function loginAction() {
31 $form = new My_Form_Login();
32 $param = $this-getRequest()-getParams();
33
34 //Init the view up here, even if we throw it out.
35 $this-initView();
36
37 if(!empty($param['submit']) $form-isValid($param)) {
38 // If the form validated, then we know there are both passwd
and value fields.
39 // Authenticate against the databse. First, get an instance.
40 $auth = Zend_Auth::getInstance();
41
42 // Let's set up the adapter. Don't forget that the password is
just hashed,
43 // while the email has had htmlspecialchars run on it before
being inserted.
44 // This also serves as our input cleaning... no bobby tables!
45 $adapt = new
Zend_Auth_Adapter_DbTable(Zend_Registry::get('db'));
46 $adapt-setTableName('users');
47 $adapt-setIdentityColumn('login');
48 $adapt-setCredentialColumn('sha1password');
49 $adapt-setCredential(sha1($param['pass']));
50 $adapt-setIdentity(htmlspecialchars($param['login']));
51
52
53 // And run the auth.
54 $result = $auth-authenticate($adapt);
55
56 // Compare the values and do stuff.
57 if($result-isValid()) {
58 $storage = new Zend_Auth_Storage_Session();
59
$storage-write($adapt-getResultRowObject(array('login','password_reset')));
60 $auth-setStorage($storage);
61 $this-_redirect('/user/index');
62 } else {
63 $this-view-message = 'Invalid login. Please try again.';
64 $this-view-form = $form;
65 }
66 } else {
67 $this-view-form = $form;
68 }
69 }
And here's the login form:
1 h1Administration Login/h1
2 ? if(!empty($this-message)): ?
3 p class=error?= $this-message ?/p
4 ? endif; ?
5 ?= $this-form ?
6
The behaviour I'm getting can be reproduced in Firefox and Safari by
repeating the following steps:
1) Going to the login form in your browser
2) Typing a username in the login field
3) Typing an incorrect password
4) The form repopulates as expected, and shows the expected error message.
5) Type another incorrect password
6) The form repopulates with the string 'login' in the login instead of
the expected user name.
Matt, I'll email you a link to my working copy so you can see the
behaviour.
Thanks!
-Karl
