12 Oct
2005
12 Oct
'05
11:14 p.m.
Hi,
how about add an 'Registration' in main.php which leads to local
registration form
this form could collect, of course after explaining and asking for
permission:
- number of servers/databases/tables handled with this installation
- currently installed versions of PHP, PMA, MySQL
- used extension mysql, mysqli
- changed configuration (different from default)
- used theme
- registration information (email, name, company, ... )
- hash of installation path (as unique id for installation)
- hash of server connection string (as unique id for servers)
- a free textfield for additional comments
this can be stored local, or at least a hash over all, to recognize
changes and update registration
and of course in the phpMyAdmin project database
so we can
- make most used settings to default
- send security alerts on specific versions
- statistics on used versions
- and much more ...
--
Sebastian Mendel
www.sebastianmendel.de
www.sf.net/projects/phpdatetime | www.sf.net/projects/phptimesheet
13 Oct
13 Oct
1:20 a.m.
Sebastian Mendel a écrit :
Hi,
how about add an 'Registration' in main.php which leads to local
registration form
this form could collect, of course after explaining and asking for
permission:
- number of servers/databases/tables handled with this installation
- currently installed versions of PHP, PMA, MySQL
- used extension mysql, mysqli
- changed configuration (different from default)
- used theme
- registration information (email, name, company, ... )
- hash of installation path (as unique id for installation)
- hash of server connection string (as unique id for servers)
- a free textfield for additional comments
this can be stored local, or at least a hash over all, to recognize
changes and update registration
and of course in the phpMyAdmin project database
so we can
- make most used settings to default
- send security alerts on specific versions
- statistics on used versions
- and much more ...
Hi Sebastian,
I guess that if we implement this, the registration form should be
displayed only to a super-user.
But I'm not sure I like the idea, for those reasons:
- I would not like to have to handle all this data
- I think that users would have a negative perception, seeing "registration"
- if we use the project database for this, we would have to remove our
demo (believe me, for security reasons)
- the whole user settings system should migrate to db-based user
preferences, and/or an installation GUI
- about the alerts, we already send them, with indications on the
affected versions
I think that download stats about themes indicate correctly the
popularity. Besides, each user of a multi-user installation can choose
his theme, so you want each user to participate in the registration?
Marc
4:06 a.m.
Marc Delisle wrote:
Sebastian Mendel a écrit :
yes
Hi,
how about add an 'Registration' in main.php which leads to local
registration form
this form could collect, of course after explaining and asking for
permission:
- number of servers/databases/tables handled with this installation
- currently installed versions of PHP, PMA, MySQL
- used extension mysql, mysqli
- changed configuration (different from default)
- used theme
- registration information (email, name, company, ... )
- hash of installation path (as unique id for installation)
- hash of server connection string (as unique id for servers)
- a free textfield for additional comments
this can be stored local, or at least a hash over all, to recognize
changes and update registration
and of course in the phpMyAdmin project database
so we can
- make most used settings to default
- send security alerts on specific versions
- statistics on used versions
- and much more ...
Hi Sebastian,
I guess that if we implement this, the registration form should be
displayed only to a super-user. But I'm not sure I like the idea, for those
reasons:
- I would not like to have to handle all this data
- I think that users would have a negative perception, seeing
"registration"
than let us call it "help for improvement" ;-)
- if we use the project database for this, we would
have to remove our
demo (believe me, for security reasons)
- the whole user settings system should migrate to db-based user
preferences, and/or an installation GUI
- about the alerts, we already send them, with indications on the
affected versions
i mean to registered users email addresses, who are registered with the
affected version
I think that download stats about themes indicate
correctly the
popularity. Besides, each user of a multi-user installation can choose
his theme, so you want each user to participate in the registration?
no, not really - only a 'installation'-registration
--
Sebastian Mendel
www.sebastianmendel.de
www.sf.net/projects/phpdatetime | www.sf.net/projects/phptimesheet
4:35 a.m.
New subject: [Phpmyadmin-devel] Re: Registration / Installationstatisitics
I merged two threads :-)
On Thu 13. 10. 2005 17:16, Sebastian Mendel wrote:
alerts only on first time to 'registered' users with this version to
given email adress - when the security alert comes the first the
vendors will mostly not have applied any patch adressing this issue
Wrong, if you install some distribution, you will get patched version,
but it is usually not current one (especially "enterprise" distribution
release cycles are very long, so you might have 3 years old patched
version). This will only force vendors to disable such checks, you can
see how similar feature in Firefox is mostly disabled in distributions.
--
Michal Čihař | http://cihar.com
Marc Delisle wrote:
Well I'd forget this until we have setup script. You can then easily add
this as part of installation, however right now it will be more
annoying:
On Thu 13. 10. 2005 17:14, Sebastian Mendel wrote:
I think that download stats about themes indicate
correctly the
popularity. Besides, each user of a multi-user installation can
choose his theme, so you want each user to participate in the
registration?
no, not really - only a 'installation'-registration Michal Čihař wrote:
In most cases you can not write to file, so you will silently fail and
still offer registration?
On Thu 13. 10. 2005 12:24, Sebastian Mendel
wrote:
or just in a file (just test for write privilelgs, if not no error) this can be stored local, or at least a hash over
all, to
recognize changes and update registration
stored where? in pmadb? this is currently only place where you can
save anything, but it is not enabled on most installations - send security alerts on specific versions
You can't handle this as vendors often backport security patches,
so you don't know whether version user has installed is really
vulnerable.
2:47 a.m.
New subject: [Phpmyadmin-devel] Re: Registration / Installationstatisitics
Hi
On Thu 13. 10. 2005 12:24, Sebastian Mendel wrote:
how about add an 'Registration' in main.php
which leads to local
registration form
People don't like registrations, I'm not sure whether effort invested
into this will return in any positive value.
this form could collect, of course after explaining
and asking for
permission:
- number of servers/databases/tables handled with this installation
number of servers is configuration, however rest are dynamic values
changing quite a lot over time
- currently installed versions of PHP, PMA, MySQL
- used extension mysql, mysqli
- changed configuration (different from default)
- used theme
this is per user settings, doesn't make much sense to collect it
- registration information (email, name, company,
... )
- hash of installation path (as unique id for installation)
- hash of server connection string (as unique id for servers)
- a free textfield for additional comments
this can be stored local, or at least a hash over all, to recognize
changes and update registration
stored where? in pmadb? this is currently only place where you can save
anything, but it is not enabled on most installations
and of course in the phpMyAdmin project database
This would mean dropping demo ... hmm I'd rather host this database than
demo, so maybe it could be solved.
so we can
- make most used settings to default
Yes, this would be helpful.
- send security alerts on specific versions
You can't handle this as vendors often backport security patches, so you
don't know whether version user has installed is really vulnerable.
- statistics on used versions
- and much more ...
--
Michal Čihař | http://cihar.com
4:02 a.m.
New subject: [Phpmyadmin-devel] Re: Registration / Installationstatisitics
Michal Čihař wrote:
oh, of course per user settings not ...
or just in a file (just test for write privilelgs, if not no error)
alerts only on first time to 'registered' users with this version to
given email adress - when the security alert comes the first the vendors
will mostly not have applied any patch adressing this issue
--
Sebastian Mendel
www.sebastianmendel.de
www.sf.net/projects/phpdatetime | www.sf.net/projects/phptimesheet
Hi
On Thu 13. 10. 2005 12:24, Sebastian Mendel wrote:
you are right, ...
how about add an 'Registration' in
main.php which leads to local
registration form
People don't like registrations, I'm not sure whether effort invested
into this will return in any positive value.
this form could collect, of course after
explaining and asking for
permission:
- number of servers/databases/tables handled with this installation
number of servers is configuration, however rest are dynamic values
changing quite a lot over time - currently
installed versions of PHP, PMA, MySQL
- used extension mysql, mysqli
- changed configuration (different from default)
- used theme
this is per user settings, doesn't make much sense to collect it -
registration information (email, name, company, ... )
- hash of installation path (as unique id for installation)
- hash of server connection string (as unique id for servers)
- a free textfield for additional comments
this can be stored local, or at least a hash over all, to recognize
changes and update registration
stored where? in pmadb? this is currently only place where you can save
anything, but it is not enabled on most installations - send
security alerts on specific versions
You can't handle this as vendors often backport security patches, so you
don't know whether version user has installed is really vulnerable. 
4:43 a.m.
New subject: [Phpmyadmin-devel] Alter Table Lacks Warnings
I recently edited a table for a column change on an enum.
The column is not null with a default set and '' is not a member of the
enum.
This is the output from PHPMyadmin where I changed 'Artist' to 'Music
Artist'
Table contact_types has been altered.
SQL query:
ALTER TABLE `contact_types` CHANGE `contact_type` `contact_type` ENUM(
'Actor', 'Actress', 'Music Artist', 'Band',
'Company', 'Unknown' ) NOT NULL
DEFAULT 'Unknown'
[ Edit ] [ Create PHP Code ]
This resulted in all the existing rows that had the value 'Artist' changing
to ''. First, I guess I expected that it would change those rows to Music
Artist but that's my own fault. Second, the fact that it didn't utilize my
default definition ended up "better" than if it had change it to
'Unknown'
However, running this from the command line results in the following output:
Query OK, 1578 rows affected, 21 warnings (0.06 sec)
Records: 1578 Duplicates: 0 Warnings: 21
mysql> show warnings;
+---------+------+------------------------------------------------------+
| Level | Code | Message |
+---------+------+------------------------------------------------------+
| Warning | 1265 | Data truncated for column 'contact_type' at row 9 |
| Warning | 1265 | Data truncated for column 'contact_type' at row 11 |
| Warning | 1265 | Data truncated for column 'contact_type' at row 39 |
| Warning | 1265 | Data truncated for column 'contact_type' at row 529 |
| Warning | 1265 | Data truncated for column 'contact_type' at row 1533 |
| Warning | 1265 | Data truncated for column 'contact_type' at row 1534 |
| Warning | 1265 | Data truncated for column 'contact_type' at row 1535 |
| Warning | 1265 | Data truncated for column 'contact_type' at row 1536 |
| Warning | 1265 | Data truncated for column 'contact_type' at row 1537 |
| Warning | 1265 | Data truncated for column 'contact_type' at row 1538 |
| Warning | 1265 | Data truncated for column 'contact_type' at row 1539 |
| Warning | 1265 | Data truncated for column 'contact_type' at row 1540 |
| Warning | 1265 | Data truncated for column 'contact_type' at row 1541 |
| Warning | 1265 | Data truncated for column 'contact_type' at row 1542 |
| Warning | 1265 | Data truncated for column 'contact_type' at row 1547 |
| Warning | 1265 | Data truncated for column 'contact_type' at row 1558 |
| Warning | 1265 | Data truncated for column 'contact_type' at row 1568 |
| Warning | 1265 | Data truncated for column 'contact_type' at row 1569 |
| Warning | 1265 | Data truncated for column 'contact_type' at row 1574 |
| Warning | 1265 | Data truncated for column 'contact_type' at row 1575 |
| Warning | 1265 | Data truncated for column 'contact_type' at row 1576 |
+---------+------+------------------------------------------------------+
21 rows in set (0.00 sec)
I believe that the existence of warnings is important and warrants a change
in PHPMyAdmin.
Thoughts?
KAM
9:43 a.m.
New subject: [Phpmyadmin-devel] Re: Alter Table Lacks Warnings
Hi
On Thu 13. 10. 2005 17:41, Kevin A. McGrail wrote:
I recently edited a table for a column change on an
enum.
The column is not null with a default set and '' is not a member of
the enum.
This is the output from PHPMyadmin where I changed 'Artist' to 'Music
Artist'
Table contact_types has been altered.
SQL query:
ALTER TABLE `contact_types` CHANGE `contact_type` `contact_type`
ENUM( 'Actor', 'Actress', 'Music Artist', 'Band',
'Company',
'Unknown' ) NOT NULL DEFAULT 'Unknown'
[ Edit ] [ Create PHP Code ]
This resulted in all the existing rows that had the value 'Artist'
changing to ''. First, I guess I expected that it would change those
rows to Music Artist but that's my own fault. Second, the fact that
it didn't utilize my default definition ended up "better" than if it
had change it to 'Unknown'
However, running this from the command line results in the following
output:
Query OK, 1578 rows affected, 21 warnings (0.06 sec)
Records: 1578 Duplicates: 0 Warnings: 21
mysql> show warnings;
+---------+------+---------------------------------------------------
---+
| Level | Code | Message |
+---------+------+---------------------------------------------------
---+
| Warning | 1265 | Data truncated for column 'contact_type' at row 9
| |
|
| Warning | 1265 | Data truncated for column 'contact_type' at row 11
| |
|
| Warning | 1265 | Data truncated for column 'contact_type' at row 39
| |
|
| Warning | 1265 | Data truncated for column 'contact_type' at row
| 529 |
|
| Warning | 1265 | Data truncated for column 'contact_type' at row
| 1533 |
|
| Warning | 1265 | Data truncated for column 'contact_type' at row
| 1534 |
|
| Warning | 1265 | Data truncated for column 'contact_type' at row
| 1535 |
|
| Warning | 1265 | Data truncated for column 'contact_type' at row
| 1536 |
|
| Warning | 1265 | Data truncated for column 'contact_type' at row
| 1537 |
|
| Warning | 1265 | Data truncated for column 'contact_type' at row
| 1538 |
|
| Warning | 1265 | Data truncated for column 'contact_type' at row
| 1539 |
|
| Warning | 1265 | Data truncated for column 'contact_type' at row
| 1540 |
|
| Warning | 1265 | Data truncated for column 'contact_type' at row
| 1541 |
|
| Warning | 1265 | Data truncated for column 'contact_type' at row
| 1542 |
|
| Warning | 1265 | Data truncated for column 'contact_type' at row
| 1547 |
|
| Warning | 1265 | Data truncated for column 'contact_type' at row
| 1558 |
|
| Warning | 1265 | Data truncated for column 'contact_type' at row
| 1568 |
|
| Warning | 1265 | Data truncated for column 'contact_type' at row
| 1569 |
|
| Warning | 1265 | Data truncated for column 'contact_type' at row
| 1574 |
|
| Warning | 1265 | Data truncated for column 'contact_type' at row
| 1575 |
|
| Warning | 1265 | Data truncated for column 'contact_type' at row
| 1576 |
+---------+------+---------------------------------------------------
---+
21 rows in set (0.00 sec)
I believe that the existence of warnings is important and warrants a
change in PHPMyAdmin.
Thoughts?
File feature request for handling MySQL warnings.
--
Michal Čihař | http://cihar.com
6861
days inactive
6861
days old
7 comments
4 participants
participants (4)
-
Kevin A. McGrail -
Marc Delisle -
Michal Čihař -
Sebastian Mendel