ANN: django-forms-builder 0.2.0 released
Hi Djangonauts, I've released a new version of django-forms-builder. It's a small Django reusable app that allows admin users to build their own forms. This release is a complete rewrite that addresses the fact that previously the fields available for forms created by admin users were restricted to a fixed set of fields defined by the developer. Admin users can now create forms with any number of fields specifying their names and field types making it a much more thorough solution. I've also added some basic tests as well as the ability for admin users to export form submissions via CSV. Grab it from pypi: http://pypi.python.org/pypi/django-forms-builder/ or github: http://github.com/stephenmcd/django-forms-builder/ or bitbucket: http://bitbucket.org/stephenmcd/django-forms-builder/ Cheers, Steve -- Stephen McDonald Twitter: http://twitter.com/stephen_mcd Linkedin: http://www.linkedin.com/in/stephenmcd -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: DjangoDash 2010 is done! Check out the projects done in 48 hours.
I'm sure there are more entries than this, but here are the ones that were posted around finishing time in IRC: http://servertail.com/ http://transphorm.me/ http://www.buzz-fire.com/ http://dash.manoria.com/ http://ratemyflight.org/ <-- my team's http://www.ihatexml.com/ http://repocracy.com/ http://permachart.appspot.com/ http://dashline.chronosbox.org/ http://readthedocs.org/ http://phonetapapp.appspot.com/ http://www.ihatexml.com/ http://hashfeedr.com/ http://drinkfindr.com/ Cheers, Steve On Aug 16, 4:07 pm, iJames wrote: > Hi programmers! > > I didn't see a posting about DjangoDash so I thought I would mention > it since I didn't participate and so I'm awake. And also because I > didn't know about it but for a single podcast I happened to listen to. > > Kudos to the awesome teams who burned up the commits! > > DjangoDash 2010 was 48 hours of straight programming from a blank git- > hub to a full working application. > > I just took a peek at some of the apps, it's an awesome testimonial to > what can be done with some good thinking and planning, 48 hours of > good coding, and an awesome framework like Django. > > Check it out here: http://www.djangodash.com > > Now back to my own Django project. It sure seems like I could be > finishing it faster... :-P > > James -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Where to create a Mezzanine project
For anyone who comes along at a later point looking for an answer to this, it was provided on the mezzanine-users mailing list. http://groups.google.com/group/mezzanine-users/browse_thread/thread/c8b13c41a3168c94 Cheers, Steve On Oct 5, 7:37 am, Sithembewena Lloyd Dube wrote: > Hi Ken, > > Thought so too. I guess I am trying to figure out if I could have a nested > project (mezzanine) inside my Django project? > > > > > > > > > > On Tue, Oct 5, 2010 at 1:04 PM, Kenneth Gonsalves wrote: > > On Tue, 2010-10-05 at 12:43 +0200, Sithembewena Lloyd Dube wrote: > > > I have installed Mezzanine and would like to know where in my main > > > Django > > > project I should run mezzanine-project. Is it recommended to create > > > the > > > mezzanine-project inside the Django project, or outside it? > > > > The mezzanine project will integrate blogs in the main Django > > > project. > > > from what I can see, mezzanine is not an app to run inside a 'main' > > django project, but a standalone project of it's own - I could be wrong > > as I have not tried it out. > > -- > > regards > > Kenneth Gonsalves > > > -- > > You received this message because you are subscribed to the Google Groups > > "Django users" group. > > To post to this group, send email to django-us...@googlegroups.com. > > To unsubscribe from this group, send email to > > django-users+unsubscr...@googlegroups.com > groups.com> > > . > > For more options, visit this group at > >http://groups.google.com/group/django-users?hl=en. > > -- > Regards, > Sithembewena Lloyd Dubehttp://www.lloyddube.com -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
ANN: Mezzanine 1.0 released
ezzanine issue tracker: https://github.com/stephenmcd/mezzanine/issues Cartridge docs: http://cartridge.jupo.org or http://cartridge.rtfd.org/ Cartridge Git repo: https://github.com/stephenmcd/cartridge Cartridge Mercurial repo: https://bitbucket.org/stephenmcd/cartridge Cartridge issue tracker: https://github.com/stephenmcd/cartridge/issues Cheers, Steve -- Stephen McDonald http://jupo.org -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: ANN: Mezzanine 1.0 released
Yes - behind the project homepage is the entire demo site where anyone can log in and try it out. I've left debug on so that when people find errors on it they can submit the traceback easily. It's been really helpful on the few occasions it has happened. On Mar 4, 12:55 pm, arshaver wrote: > Looks great. One thing... looks likehttp://mezzanine.jupo.org/is > running with Debug = True (tryhttp://mezzanine.jupo.org/asdf). Maybe > you're aware, just FYI. > > On Mar 3, 3:51 pm, Stephen McDonald wrote: > > > > > > > > > Hi Djangonauts, > > > I'm happy to announce the release of Mezzanine 1.0. Mezzanine is simple yet > > powerful BSD licensed CMS for building Django powered sites. > > > Development of Mezzanine and its sister project Cartridge (ecommerce for > > Mezzanine) began over two years ago, born from frustrations with the only > > options available at the time which were django-page-cms and Satchmo, and > > from a decade's experience in building proprietary CMSes and ecommerce > > solutions, prior to working with Django. Since then it has grown from real > > world requirements at a fast paced web development agency in Australia, and > > has received contributions from many dozens of developers on GitHub and > > Bitbucket, with a wider community of hundreds on the mailing list. > > Mezzanine and Cartridge have been used to power a long list of production > > sites, from personal blogs and agency sites, to some of the highest traffic > > content sites and ecommerce stores for some of the largest brands in > > Australia. > > > Here's an overview of Mezzanine's features: > > > - Hierarchical navigation tree, with page nodes extendable by Mezzanine's > > content type system. Content types are simply subclases of Mezzanine's Page > > model - subclass away and your new type is available. > > - Inline front-end site editing that can be applied to any models: > > Mezzanine's, third party apps, or your own. > > - Blogging app (regular Django app). > > - Gallery app (a Mezzanine content type). > > - Mobile device handling. Build separate mobile versions of templates where > > required to run a mobile version of the site - no separate URLs or views > > required. > > - Form builder app (a Mezzanine content type). Admin users create their own > > forms, and view form submissions via the admin, or export them via CSV. > > - Mezzanine projects are standard Django projects - admin, urlpatterns, > > views, models. Third party Django apps plug straight in without special > > handling. > > - Built-in search engine. > > - South migrations. > > - Admin editable settings. > > - Full test suite, continuously integrated (with Travis CI) including > > automated pep8/pyflakes integration. The code base is painstakingly clean. > > - Fully documented, available on the Mezzanine project site as well as on > > Read The Docs. > > - Translated into around a dozen languages, managed via Transifex. > > - Grappelli/Filebrowser based admin. Third party Django admin classes plug > > straight in. > > - Full featured ecommerce via Cartridge - a separate ecommerce app built > > for Mezzanine. > > - All functionality comes with default templates to get you started, > > integrated with Bootstrap 2.0. > > - Integrated with Django's sites app. > > - A set of generic foreignkey types and models: tagging, threaded comments > > and ratings. All denormalised with counts, averages, etc. > > > To be honest, you could almost implement everything Mezzanine does by > > combining dozens of different open source Django apps that are out there. > > What you get from Mezzanine though, is everything integrated seamlessly out > > of the box, leaving you free to focus on building your site. > > > In conjunction with the Mezzanine 1.0 release, I've also released Cartridge > > 0.4. As I mentioned, Cartridge provides a full ecommerce package for > > Mezzanine. While Mezzanine is more of a framework for building sites with > > any type of content you need to, Cartridge is much more opinionated in its > > function, namely how a store should be set up, and is more of a standard > > Django app that implements the most common features you'd find in an online > > store. Like Mezzanine, Cartridge has been under development for a couple of > > years now. Since I haven't posted to django-users about either Mezzanine or > > Cartridge before, here's an overview of Cartridge's features as well: > > > - Hierarchical shop categories. These are just Mezzanine content types a
Re: ANN: Mezzanine 1.0 released
Thank you. I don't think the dependency will ever go away. It would be like trying to remove Django as a dependency of Mezzanine. Cartridge heavily leverages many aspects of Mezzanine. On Mar 4, 2:16 pm, "uno...@gmail.com" wrote: > Stephen, > > Amazing work with Mezzanine and Cartridge. One question I had for you > - have you considered separating Cartridge from the dependency on > Mezzanine. I think Cartridge adoption will increase quite a lot if the > interdependency is removed. I realize though, that this means more > issues with managing both projects and added work to maintain both of > them. But just a thought. > > On Mar 3, 3:51 pm, Stephen McDonald wrote: > > > > > > > > > Hi Djangonauts, > > > I'm happy to announce the release of Mezzanine 1.0. Mezzanine is simple yet > > powerful BSD licensed CMS for building Django powered sites. > > > Development of Mezzanine and its sister project Cartridge (ecommerce for > > Mezzanine) began over two years ago, born from frustrations with the only > > options available at the time which were django-page-cms and Satchmo, and > > from a decade's experience in building proprietary CMSes and ecommerce > > solutions, prior to working with Django. Since then it has grown from real > > world requirements at a fast paced web development agency in Australia, and > > has received contributions from many dozens of developers on GitHub and > > Bitbucket, with a wider community of hundreds on the mailing list. > > Mezzanine and Cartridge have been used to power a long list of production > > sites, from personal blogs and agency sites, to some of the highest traffic > > content sites and ecommerce stores for some of the largest brands in > > Australia. > > > Here's an overview of Mezzanine's features: > > > - Hierarchical navigation tree, with page nodes extendable by Mezzanine's > > content type system. Content types are simply subclases of Mezzanine's Page > > model - subclass away and your new type is available. > > - Inline front-end site editing that can be applied to any models: > > Mezzanine's, third party apps, or your own. > > - Blogging app (regular Django app). > > - Gallery app (a Mezzanine content type). > > - Mobile device handling. Build separate mobile versions of templates where > > required to run a mobile version of the site - no separate URLs or views > > required. > > - Form builder app (a Mezzanine content type). Admin users create their own > > forms, and view form submissions via the admin, or export them via CSV. > > - Mezzanine projects are standard Django projects - admin, urlpatterns, > > views, models. Third party Django apps plug straight in without special > > handling. > > - Built-in search engine. > > - South migrations. > > - Admin editable settings. > > - Full test suite, continuously integrated (with Travis CI) including > > automated pep8/pyflakes integration. The code base is painstakingly clean. > > - Fully documented, available on the Mezzanine project site as well as on > > Read The Docs. > > - Translated into around a dozen languages, managed via Transifex. > > - Grappelli/Filebrowser based admin. Third party Django admin classes plug > > straight in. > > - Full featured ecommerce via Cartridge - a separate ecommerce app built > > for Mezzanine. > > - All functionality comes with default templates to get you started, > > integrated with Bootstrap 2.0. > > - Integrated with Django's sites app. > > - A set of generic foreignkey types and models: tagging, threaded comments > > and ratings. All denormalised with counts, averages, etc. > > > To be honest, you could almost implement everything Mezzanine does by > > combining dozens of different open source Django apps that are out there. > > What you get from Mezzanine though, is everything integrated seamlessly out > > of the box, leaving you free to focus on building your site. > > > In conjunction with the Mezzanine 1.0 release, I've also released Cartridge > > 0.4. As I mentioned, Cartridge provides a full ecommerce package for > > Mezzanine. While Mezzanine is more of a framework for building sites with > > any type of content you need to, Cartridge is much more opinionated in its > > function, namely how a store should be set up, and is more of a standard > > Django app that implements the most common features you'd find in an online > > store. Like Mezzanine, Cartridge has been under development for a couple of > > years now. Since I haven't posted to django-users about ei
Re: ANN: Mezzanine 1.0 released
This is going back a few years, so things could be a lot different now, but here are the areas we addressed: - Database performance. We had some Satchmo sites that would spin up several hundred queries when rendering out a category. Cartridge goes to great lengths to ensure this never happens. There are never any n+1 query scenarios, and we have unit tests in place that ensure this. - Product management interface. We handed Django's admin with Satchmo over to clients, and they just didn't get it. Neither did we at first. In some case you had to go through a dozen or so screens to set up a product. Cartridge has a single screen for managing a product, and it supports 0 to N variations based on applied product options (colour, size, anything). - Grokking the overal system design. Satchmo is monolithic. Getting stuck into the code base has a significant learning curve. Cartridge is a single Django app, with one module for each of the models, views and forms. It's relatively much easier to dive into and understand. I feel really awkward ragging on Satchmo or any other project that has had hundreds of hours poured into it. And back then, in the end we did make it work for some really large clients (Toys R Us among others). But those are the pain points we faced, and addressed directly with Cartridge. On the other hand Satchmo has a ridiculous amount of features that go beyond what Cartridge has, as listed in my original email. Our philosophy was to implement the most common features an online store needs, in order to keep the code and design as simple as possible, allowing it to be easily dived into in order to implement that extra bit of customisation you might require. 75% of the features you need up front with a day or two to add the remaning custom 25%, as opposed to 95% of the features up front with weeks for implementing the remaining 5%. Cheers, Steve On Mar 4, 3:05 pm, Bolang wrote: > On 03/04/2012 06:51 AM, Stephen McDonald wrote: > > > > > > > > > > > In conjunction with the Mezzanine 1.0 release, I've also released > > Cartridge 0.4. As I mentioned, Cartridge provides a full ecommerce > > package for Mezzanine. While Mezzanine is more of a framework for > > building sites with any type of content you need to, Cartridge is much > > more opinionated in its function, namely how a store should be set up, > > and is more of a standard Django app that implements the most common > > features you'd find in an online store. Like Mezzanine, Cartridge has > > been under development for a couple of years now. Since I haven't posted > > to django-users about either Mezzanine or Cartridge before, here's an > > overview of Cartridge's features as well: > > > - Hierarchical shop categories. These are just Mezzanine content types > > and hook into your site's navigation. > > - Single interface for setting up a product, with 0 to N variations. > > - Arbitrary product options (colours, sizes, etc). > > - Hooks for shipping calculations and payment gateway. > > - Sale pricing. > > - Promotional discount codes. > > - PDF invoice generation (for packing slips). > > - Stock control. > > - Dynamic categories (by price range, colour, etc). > > - Registered or anonymous checkout. > > - Configurable nunber of checkout steps. > > Very interesting. > Can you share pros & cons between cartridge & satchmo? > > Can it support multishop? (i.e. one cartrdge installation for multiple > shops) -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Admin user privilege elevation (how to prevent it)
Stephen from Mezzanine here - thanks for the thorough response Russ.
The cleansing process we go through is very rigorous - we're leaning
on the shoulders of tools that have solved this problem (in our case
the bleach library). It uses a white-list of tags and attributes, so
all those tricky edge cases around event handlers as attributes are
solved with a well-documented white-list based on known XSS vectors.
The reality of it is though, is that you're going to have projects
where the people paying for it want to be able to add their own HTML
content, scripts included. In this case I feel the correct approach is
to give them this option, and educate them on the consequences, and
subsequent level of trust required for anyone they give access to.
So we've ended up defining a setting with various cleansing levels -
the default is high, which will strip out any possible vector via tag/
attribute. The next is medium, which will allow things such as tags
required for embedding video. We had multiple reports within days of
adding the cleansing process: "help! I've updated to the latest
version and I can't add videos anymore". With this level we still
remove scripts and known event handling tag attributes. There's
probably an exploitable vector even with the tags and attributes we
allow simply for embedding videos. Then the final level disables
cleansing entirely - you can turn it off, please know what you're
doing (with very loud warnings shown around this).
I fully appreciate the technical approach of never trusting user
content, and if I had it my way, this is the path we would take. But
in reality it just doesn't cut it. Users need these features, and
every scenario is going to be different - different content
requirements, different user structures. I feel like the approach
we've taken is the closest we can get to balancing security and
usability.
On May 12, 12:13 pm, Russell Keith-Magee
wrote:
> On Sat, May 12, 2012 at 5:11 AM, Josh Cartmell wrote:
> > I work a lot with Mezzanine which is a CMS that uses Django. A
> > security issue was recently revealed where an admin user, lets call
> > him A, (they can post rich content) could put a cleverly constructed
> > javascript on a page such that if a superuser, let's call her B, then
> > visited the page it would elevate A to superuser status (a more
> > thorough explanation is here:
> >http://groups.google.com/group/mezzanine-users/browse_thread/thread/1...).
> > Apparently any django app which allowed admin users to post arbitrary
> > html would be vulnerable.
>
> > My first thought was that csrf protection should prevent this but alas
> > that is not the case. The only real solution found is to restrict
> > admin users from posting any javascript in their content, unless you
> > completely trust the admin users.
>
> This isn't a CSRF issue. CSRF stands for Cross Site Request Forgery. A
> CSRF attack is characterised by:
>
> * A user U on site S, who has credentials for the site S, and is logged in.
>
> * An attacking site X that is visited by U.
>
> * Site X submits a form (by POST or GET) directly to site S; because
> U is logged in on S, the post is accepted as if it came from U
> directly.
>
> CSRF protection ensures that site X can't submit the form on the
> behalf of U - the CSRF token isn't visible to the attacker site, so
> they can't provide a token that will allow their submission to be
> accepted.
>
> What you're referring to is an injection attack. An injection attack
> occurs whenever user content is accepted and trusted on face value;
> the attack occurs when that content is then rendered.
>
> The canonical example of an injection is "little johnny
> tables":http://xkcd.com/327/
>
> However, the injected content isn't just SQL; all sorts of content can
> be injected for an attack. In this case, you're talking about B
> injecting javascript onto a page viewed by A; when A views the page,
> the javascript will be executed with A's permissions, allowing B to
> modify the site as if they A.
>
> Django already has many forms of protection against injection attacks.
> In this case, the protection comes by way of Django's default template
> rendering using escaped mode. If you have a template:
>
> {{ content }}
>
> and context (possibly extracted from the database):
>
> alert('hello')
>
> Django will render this as:
>
>