Ian Bicking wrote:
Ian Bicking wrote:
Martin v. Löwis wrote:
There's an XSS concern if users can upload arbitrary HTML. Approval
would address some of that, but it might be better to avoid the issue
altogether.
One way to handle that would be to host each package's documentation on
a different domain. E.g., package.pypi.python.org.
Can you please elaborate? What is the issue, and how could creating
domains resolve it?
The issue is that you can put in Javascript that does XMLHttpRequests
to other URLs on the same domain, and those requests can do things
like change a user's password, delete packages, etc. The Javascript
will be run as the person who is viewing the page. So if I am logged
in to PyPI and view some random page on pypi.python.org, and that page
contains malicious Javascript, that malicious Javascript can do
anything on pypi.python.org as though it was me doing it.
You can't make XMLHttpRequests across domains, so by putting each
package on its own domain you avoid the problem.
On second thought, simply by using a read-only domain (one that has no
admin on the domain itself) you'd also be fine. So
http://pypidocs.python.org/package/* would work fine, so long as all the
management for that remained on pypi.python.org.
I personally like domains for projects, though package.pypi.python.org
is a bit long winded anyway. A new top-level domain (pypackage.org or
pyforge.org or something) would mitigate that. But any place to drop
docs would be nice. Especially with Sphinx I think we'll get more
libraries with multi-page HTML docs.
What about distribution names with dots in them? Or worse, spaces? Both
are allowed by setuptools and PyPI and I've seen them in the wild
(especially dotted distribution names aren't uncommon when a namespaced
package is distributed under its package name, e.g. zope.interface).
_______________________________________________
Catalog-SIG mailing list
Catalog-SIG@python.org
http://mail.python.org/mailman/listinfo/catalog-sig
