| 2015-03-07 10:10:37 |
Ankush Sharma |
bug |
|
|
added bug |
| 2015-03-07 10:26:44 |
Ankush Sharma |
description |
The hash(#) is a valid character as far as the local part of the email addresses is concerned. So, as the mailing list addresses are email addresses too, we can use # in the list names too. And, in context with mailman it works well. We can create a list with list_id sam#hashed.host.org for the address sam#hashed@host.org . This works fine. But it makes the list_id to contain the hash character and therefore the REST endpoint for retrieving list wise info becomes invalid, i.e :
<api-root>/lists/sam#hashed.host.org
Because in an URL the stuff after # is treated as document starting point i.e an id identifier or something of a dom element. This is not a valid PATH for the server. Therefore the falcon wsgi request object does not contain information of that and the req.path simply returns sam as the list_id ( http://bazaar.launchpad.net/~mailman-coders/mailman/3.0/view/head:/src/mailman/rest/wsgiapp.py#L65 ) giving a 404 because there is no any list with list id sam.
The mailman client works fine, it sends a GET to <api-root>lists/sam#hashed.host.org.
This causes the REST end points which needs list_id to return 404 or in worse we can have a list_id clash between ids sam#XXXXX and sam. Further more if the list_id starts with a # character then the server finds list_id to be empty string and therefore we get a KEY ERROR because fqdn_listname is not set too. The bug highly effects postorius too. The lists index template at /postorius/lists/ cannot be rendered as it uses the former REST endpoint and again a 404 is given. And, until we delete this list from the database, we cann't do anything except of getting a 404 and KEY ERROR each time.
As far as security is concerned, if an another user created a public list using a hash character, then public list indexing would also fail. |
The hash(#) is a valid character as far as the local part of the email addresses is concerned. So, as the mailing list addresses are email addresses too, we can use # in the list names too. And, in context with mailman it works well. We can create a list with list_id sam#hashed.host.org for the address sam#hashed@host.org . This works fine. But it makes the list_id to contain the hash character and therefore the REST endpoint for retrieving list wise info becomes invalid, i.e :
<api-root>/lists/sam#hashed.host.org
Because in an URL the stuff after # is treated as document starting point i.e an id identifier or something of a dom element. This is not a valid PATH for the server. Therefore the falcon wsgi request object does not contain information of that and the req.path simply returns sam as the list_id ( http://bazaar.launchpad.net/~mailman-coders/mailman/3.0/view/head:/src/mailman/rest/wsgiapp.py#L65 ) giving a 404 because there is no any list with list id sam.
The mailman client works fine, it sends a GET to <api-root>lists/sam#hashed.host.org.
This causes the REST end points which needs list_id to return 404 or in worse we can have a list_id clash between ids sam#XXXXX and sam. Further more if the list_id starts with a # character then the server finds list_id to be empty string and therefore we get a KEY ERROR because fqdn_listname is not set too. The bug highly effects postorius too. The lists index template at /postorius/lists/ cannot be rendered as it uses the former REST endpoint and again a 404 is given. And, until we delete this list from the database, we can't do anything except of getting a 404 and KEY ERROR each time.
As far as security is concerned, if an another user created a public list using a hash character, then public list indexing would also fail. |
|
| 2015-03-07 10:40:06 |
Ankush Sharma |
bug task added |
|
postorius |
|
| 2015-03-08 12:13:42 |
Ankush Sharma |
mailman: status |
New |
Confirmed |
|
| 2015-03-08 12:13:46 |
Ankush Sharma |
postorius: status |
New |
Confirmed |
|
| 2015-03-08 12:13:51 |
Ankush Sharma |
mailman: assignee |
|
Ankush Sharma (black-perl) |
|
| 2015-03-08 12:13:54 |
Ankush Sharma |
postorius: assignee |
|
Ankush Sharma (black-perl) |
|
| 2015-03-08 18:31:30 |
Ankush Sharma |
description |
The hash(#) is a valid character as far as the local part of the email addresses is concerned. So, as the mailing list addresses are email addresses too, we can use # in the list names too. And, in context with mailman it works well. We can create a list with list_id sam#hashed.host.org for the address sam#hashed@host.org . This works fine. But it makes the list_id to contain the hash character and therefore the REST endpoint for retrieving list wise info becomes invalid, i.e :
<api-root>/lists/sam#hashed.host.org
Because in an URL the stuff after # is treated as document starting point i.e an id identifier or something of a dom element. This is not a valid PATH for the server. Therefore the falcon wsgi request object does not contain information of that and the req.path simply returns sam as the list_id ( http://bazaar.launchpad.net/~mailman-coders/mailman/3.0/view/head:/src/mailman/rest/wsgiapp.py#L65 ) giving a 404 because there is no any list with list id sam.
The mailman client works fine, it sends a GET to <api-root>lists/sam#hashed.host.org.
This causes the REST end points which needs list_id to return 404 or in worse we can have a list_id clash between ids sam#XXXXX and sam. Further more if the list_id starts with a # character then the server finds list_id to be empty string and therefore we get a KEY ERROR because fqdn_listname is not set too. The bug highly effects postorius too. The lists index template at /postorius/lists/ cannot be rendered as it uses the former REST endpoint and again a 404 is given. And, until we delete this list from the database, we can't do anything except of getting a 404 and KEY ERROR each time.
As far as security is concerned, if an another user created a public list using a hash character, then public list indexing would also fail. |
The hash(#) is a valid character as far as the local part of the email addresses is concerned. So, as the mailing list addresses are email addresses too, we can use # in the list names too. And, in context with mailman it works well. We can create a list with list_id sam#hashed.host.org for the address sam#hashed@host.org . This works fine. But it makes the list_id to contain the hash character and therefore the REST endpoint for retrieving list wise info becomes invalid, i.e :
<api-root>/lists/sam#hashed.host.org
Because in an URL the stuff after # is treated as document starting point i.e an id identifier or something of a dom element. This is not a valid PATH for the server. Therefore the falcon wsgi request object does not contain information of that and the req.path simply returns sam as the list_id ( http://bazaar.launchpad.net/~mailman-coders/mailman/3.0/view/head:/src/mailman/rest/wsgiapp.py#L65 ) giving a 404 because there is no any list with list id sam.
The mailman client works fine, it sends a GET to <api-root>lists/sam#hashed.host.org.
This causes the REST end points which needs list_id to return 404 or in worse we can have a list_id clash between ids sam#XXXXX and sam. Further more if the list_id starts with a # character then the server finds list_id to be empty string and therefore we get a KEY ERROR because fqdn_listname is not set too. The bug highly effects postorius too. The lists index template at /postorius/lists/ cannot be rendered as it uses the former REST endpoint and again a 404 is given. And, until we delete this list from the database, we can't do anything except of getting a 404 and KEY ERROR each time. |
|
| 2015-03-08 18:57:41 |
Ankush Sharma |
description |
The hash(#) is a valid character as far as the local part of the email addresses is concerned. So, as the mailing list addresses are email addresses too, we can use # in the list names too. And, in context with mailman it works well. We can create a list with list_id sam#hashed.host.org for the address sam#hashed@host.org . This works fine. But it makes the list_id to contain the hash character and therefore the REST endpoint for retrieving list wise info becomes invalid, i.e :
<api-root>/lists/sam#hashed.host.org
Because in an URL the stuff after # is treated as document starting point i.e an id identifier or something of a dom element. This is not a valid PATH for the server. Therefore the falcon wsgi request object does not contain information of that and the req.path simply returns sam as the list_id ( http://bazaar.launchpad.net/~mailman-coders/mailman/3.0/view/head:/src/mailman/rest/wsgiapp.py#L65 ) giving a 404 because there is no any list with list id sam.
The mailman client works fine, it sends a GET to <api-root>lists/sam#hashed.host.org.
This causes the REST end points which needs list_id to return 404 or in worse we can have a list_id clash between ids sam#XXXXX and sam. Further more if the list_id starts with a # character then the server finds list_id to be empty string and therefore we get a KEY ERROR because fqdn_listname is not set too. The bug highly effects postorius too. The lists index template at /postorius/lists/ cannot be rendered as it uses the former REST endpoint and again a 404 is given. And, until we delete this list from the database, we can't do anything except of getting a 404 and KEY ERROR each time. |
The hash(#) is a valid character as far as the local part of the email addresses is concerned. So, as the mailing list addresses are email addresses too, we can use # in the list names too. And, in context with mailman it works well. We can create a list with list_id sam#hashed.host.org for the address sam#hashed@host.org . This works fine. But it makes the list_id to contain the hash character and therefore the REST endpoint for retrieving list wise info becomes invalid, i.e :
<api-root>/lists/sam#hashed.host.org
Because in an URL the stuff after # is treated as document starting point i.e an id identifier or something of a dom element. This is not a valid PATH for the server. Therefore the falcon wsgi request object does not contain information of that and the req.path simply returns sam as the list_id ( http://bazaar.launchpad.net/~mailman-coders/mailman/3.0/view/head:/src/mailman/rest/wsgiapp.py#L65 ) giving a 404 because there is no any list with list id sam.
The mailman client works fine, it sends a GET to <api-root>lists/sam#hashed.host.org.
This causes the REST end points which needs list_id to return 404 or in worse we can have a list_id clash between ids sam#XXXXX and sam. Further more if the list_id starts with a # character then the server finds list_id to be empty string and therefore we get a KEY ERROR because fqdn_listname is not set too. The bug highly effects postorius too. The lists index template at /postorius/lists/ cannot be rendered as it uses the former REST endpoint and again a 404 is given. And, until we delete this list from the database, we can't do anything except of getting a 404 and KEY ERROR each time.
Bug discussed in detail here: http://www.mail-archive.com/mailman-developers%40python.org/msg15317.html |
|
| 2015-03-09 18:35:10 |
Ankush Sharma |
description |
The hash(#) is a valid character as far as the local part of the email addresses is concerned. So, as the mailing list addresses are email addresses too, we can use # in the list names too. And, in context with mailman it works well. We can create a list with list_id sam#hashed.host.org for the address sam#hashed@host.org . This works fine. But it makes the list_id to contain the hash character and therefore the REST endpoint for retrieving list wise info becomes invalid, i.e :
<api-root>/lists/sam#hashed.host.org
Because in an URL the stuff after # is treated as document starting point i.e an id identifier or something of a dom element. This is not a valid PATH for the server. Therefore the falcon wsgi request object does not contain information of that and the req.path simply returns sam as the list_id ( http://bazaar.launchpad.net/~mailman-coders/mailman/3.0/view/head:/src/mailman/rest/wsgiapp.py#L65 ) giving a 404 because there is no any list with list id sam.
The mailman client works fine, it sends a GET to <api-root>lists/sam#hashed.host.org.
This causes the REST end points which needs list_id to return 404 or in worse we can have a list_id clash between ids sam#XXXXX and sam. Further more if the list_id starts with a # character then the server finds list_id to be empty string and therefore we get a KEY ERROR because fqdn_listname is not set too. The bug highly effects postorius too. The lists index template at /postorius/lists/ cannot be rendered as it uses the former REST endpoint and again a 404 is given. And, until we delete this list from the database, we can't do anything except of getting a 404 and KEY ERROR each time.
Bug discussed in detail here: http://www.mail-archive.com/mailman-developers%40python.org/msg15317.html |
The hash(#) and question mark(?) is a valid character as far as the local part of the email addresses is concerned.
Reference: http://stackoverflow.com/questions/2049502/what-characters-are-allowed-in-email-address
So, as the mailing list addresses are email addresses too, we can use # in the list names too. And, in context with mailman it works well. We can create a list with list_id sam#hashed.host.org for the address sam#hashed@host.org . This works fine. But it makes the list_id to contain the hash character and therefore the REST endpoint for retrieving list wise info becomes invalid, i.e :
<api-root>/lists/sam#hashed.host.org
Because in an URL the stuff after # is treated as document starting point i.e an id identifier or something of a dom element. This is not a valid PATH for the server. Therefore the falcon wsgi request object does not contain information of that and the req.path simply returns sam as the list_id ( http://bazaar.launchpad.net/~mailman-coders/mailman/3.0/view/head:/src/mailman/rest/wsgiapp.py#L65 ) giving a 404 because there is no any list with list id sam.
The mailman client works fine, it sends a GET to <api-root>lists/sam#hashed.host.org.
This causes the REST end points which needs list_id to return 404 or in worse we can have a list_id clash between ids sam#XXXXX and sam. Further more if the list_id starts with a # character then the server finds list_id to be empty string and therefore we get a KEY ERROR because fqdn_listname is not set too. The bug highly effects postorius too. The lists index template at /postorius/lists/ cannot be rendered as it uses the former REST endpoint and again a 404 is given. And, until we delete this list from the database, we can't do anything except of getting a 404 and KEY ERROR each time.
Bug discussed in detail here: http://www.mail-archive.com/mailman-developers%40python.org/msg15317.html |
|
| 2015-03-13 03:25:15 |
Ankush Sharma |
tags |
mailman3 postorius |
mailman.client mailman3 postorius |
|
| 2015-03-13 03:26:35 |
Ankush Sharma |
branch linked |
|
lp:~black-perl/mailman.client/handling-special-chars-in-email |
|
| 2015-03-13 08:37:31 |
Ankush Sharma |
bug task added |
|
mailman.client |
|
| 2015-03-13 08:38:19 |
Ankush Sharma |
mailman.client: status |
New |
Confirmed |
|
| 2015-03-13 08:38:23 |
Ankush Sharma |
mailman.client: assignee |
|
Ankush Sharma (black-perl) |
|
| 2015-03-13 09:05:16 |
Ankush Sharma |
branch linked |
|
lp:~black-perl/mailman/handling-special-chars-in-email |
|
| 2015-03-13 09:19:18 |
Ankush Sharma |
branch unlinked |
lp:~black-perl/mailman/handling-special-chars-in-email |
|
|
| 2015-03-13 09:22:50 |
Ankush Sharma |
branch linked |
|
lp:~black-perl/mailman/handling-special-chars-in-email |
|
| 2015-03-13 09:25:52 |
Ankush Sharma |
branch unlinked |
lp:~black-perl/mailman/handling-special-chars-in-email |
|
|
| 2015-03-13 09:31:51 |
Ankush Sharma |
branch linked |
|
lp:~black-perl/mailman/handling-special-chars-in-email |
|
| 2015-03-13 14:15:54 |
Ankush Sharma |
branch linked |
|
lp:~black-perl/mailman.client/handling-special-chars-in-email |
|
| 2015-03-13 14:18:31 |
Ankush Sharma |
mailman: status |
Confirmed |
In Progress |
|
| 2015-03-13 14:18:35 |
Ankush Sharma |
mailman.client: status |
Confirmed |
In Progress |
|
| 2015-03-13 14:18:39 |
Ankush Sharma |
postorius: status |
Confirmed |
In Progress |
|
