preparing for a Smug 0.6 release

[Andrew McNabb]

I'd like to release Smug 0.6 soon, which will have some
backwards-incompatible changes in urls.py. I'm using the current
version on my site, but it would be great if others could test the code
and check the documentation (which should be up to date).

As far as backwards-incompatible changes go, make sure to change your
urls.py, and change your templates to use "baseurl" or "{% url %}"
instead of "basepath". The documentation should be clear on how to set
the urlconf and on how to use "baseurl" (which is almost, but not quite
the same as "basepath").

Starting with Smug 0.6, we'll be releasing tarballs in addition to
pointing people at the Git repository. Also, the project now comes with
a setup.py and is included on the Python Package Index (for
easy_installability).

Give the current version (0.6b1) a test, and let me know if you have any
problems.

Thanks.

--
Andrew McNabb
http://www.mcnabbs.org/andrew/
PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868

[Jeff Anderson]

On Tue, Jul 14, 2009 at 03:09:30PM -0600, Andrew McNabb wrote:
> Give the current version (0.6b1) a test, and let me know if you have any
> problems.

Hello,

I am running into a problem. I'm using Django 1.1 and smug 0.6b1, both
installed using easy_install :).

The exceptionally short traceback has made it hard for me to decide
where to start, so I figured I'd share here before spending too much
time chasing down the problem.

Environment:

Request Method: GET
Request URL: http://localhost:8000/
Django Version: 1.1
Python Version: 2.6.2
Installed Applications:
['django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.sites',
'smug']
Installed Middleware:
('django.middleware.common.CommonMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware')

Traceback:
File "/home/janderson/local/lib/python2.5/site-packages/Django-1.1-py2.5.egg/django/core/handlers/base.py" in get_response
92. response = callback(request, *callback_args, **callback_kwargs)

Exception Type: TypeError at /
Exception Value: page() got an unexpected keyword argument 'session'

This is a new install, I tried to follow the advanced setup guide as
closely as I could. This same problem has popped up for me twice (on
different days) so I figure there is something that I am either missing
that is in fact in the documentation, or there is something missing from
the documentation itself. :)

Here's the checklist of what I did to reproduce this:

* startproject
* add smug to INSTALLED_APPS
* added SMUG_REPOSITORIES
* added "from smug.urls import smugurl" to urls.py
* added "url(r'', include('smug.urls'))," to urlpatterns
* added "smugurl(r'', repo='work')," to urlpatterns
* start dev server->page view-> error

Let me know what I should do differently.

Jeff Anderson

[Andrew McNabb]

On Tue, Sep 15, 2009 at 05:32:32PM -0600, Jeff Anderson wrote:
>
> The exceptionally short traceback has made it hard for me to decide
> where to start, so I figured I'd share here before spending too much
> time chasing down the problem.

It looks like one of the views didn't have a **kwds to catch all keyword
arguments. I'm not quite sure why we didn't catch this earlier, but it
definitely looks like a bug. I just committed a fix, so let me know if
you still see any problems. Thanks.

[Jeff Anderson]

On Tue, Sep 15, 2009 at 09:05:28PM -0600, Andrew McNabb wrote:
> On Tue, Sep 15, 2009 at 05:32:32PM -0600, Jeff Anderson wrote:
> > The exceptionally short traceback has made it hard for me to decide
> > where to start, so I figured I'd share here before spending too much
> > time chasing down the problem.
>
> It looks like one of the views didn't have a **kwds to catch all keyword
> arguments. I'm not quite sure why we didn't catch this earlier, but it
> definitely looks like a bug. I just committed a fix, so let me know if
> you still see any problems. Thanks.

The change seems to have fixed this issue.

Thanks!

Jeff Anderson

[Jeff Anderson]

Andrew McNabb wrote:
> I'd like to release Smug 0.6 soon, which will have some
> backwards-incompatible changes in urls.py. I'm using the current
> version on my site, but it would be great if others could test the code
> and check the documentation (which should be up to date).
>
> As far as backwards-incompatible changes go, make sure to change your
> urls.py, and change your templates to use "baseurl" or "{% url %}"
> instead of "basepath". The documentation should be clear on how to set
> the urlconf and on how to use "baseurl" (which is almost, but not quite
> the same as "basepath").
>
> Starting with Smug 0.6, we'll be releasing tarballs in addition to
> pointing people at the Git repository. Also, the project now comes with
> a setup.py and is included on the Python Package Index (for
> easy_installability).
>
> Give the current version (0.6b1) a test, and let me know if you have any
> problems.

Hello,

My first use of the new smug changes was for a new project. I decided to
make my personal notes at work available through smug. Easy install
worked great. After the bug fix that Andrew committed, the whole thing
worked fine. I only use the rst2html filter in that branch. I haven't
yet tested edits on that installation.

I've finally gotten around to getting my own site working with these
smug updates. I currently run smug with two of my branches applied:
prefix, and rst-enhancements. rst-enhancements is a fork from my prefix
branch, so technically I guess it is really only "one" branch that I use.

I've merged the new code into both of those branches, and to my
dotsmug-defaults branch. All three branches are available on my git
repository: git://saffron.programmerq.net/smug.git

The master branch in that repository is what I'm using on my site. The
new smug changes along with my modifications seem to be working well.

One thing that I have noticed is that on my site, in which I have
SESSION_COOKIE_SECURE set to True. The behavior that I've observed with
this is that if I access any smug pages over http, it will always show
me as logged out. This is still the case. I've always just added the
:edit (now ?edit with the changes) to the end of my URL, and it
redirects me to the https equivalent, and allows me to make the edit.
The behavior that I'm seeing now, is that ?edit doesn't redirect me to
the https equivalent, and if I explicitly use https when I enter the URL
to edit a page, smug redirects me back to http and believes I am trying
to edit anonymously.

I'm not sure what would have changed that would break logged-in edits.
Also, I'm not a fan of only being able to be logged into https as far as
the menu is concerned. It'd be nice to have an http session cookie that
would tell the menu to render as though I was logged in, but not allow
edits or changes. I don't know if this is possible, but it'd make the
SESSION_COOKIE_SECURE option in smug a little nicer for end users who
don't understand the idea of secure sessions only.

Thanks!

Jeff Anderson

[Andrew McNabb]

On Sun, Sep 20, 2009 at 01:47:24PM -0600, Jeff Anderson wrote:
>
> I've finally gotten around to getting my own site working with these
> smug updates. I currently run smug with two of my branches applied:
> prefix, and rst-enhancements. rst-enhancements is a fork from my prefix
> branch, so technically I guess it is really only "one" branch that I use.

Didn't I merge in your prefix branch a month or two ago? If it's not
merged, then I'm really confused. :)

> One thing that I have noticed is that on my site, in which I have
> SESSION_COOKIE_SECURE set to True. The behavior that I've observed with
> this is that if I access any smug pages over http, it will always show
> me as logged out. This is still the case. I've always just added the
> :edit (now ?edit with the changes) to the end of my URL, and it
> redirects me to the https equivalent, and allows me to make the edit.
> The behavior that I'm seeing now, is that ?edit doesn't redirect me to
> the https equivalent, and if I explicitly use https when I enter the URL
> to edit a page, smug redirects me back to http and believes I am trying
> to edit anonymously.

A week or two ago, Matt Gardner noticed that caching was
over-aggressive, so that when you log in, it shows you the cached page
from before you logged in. Could this bug explain the behavior you're
seeing?

Thanks for your testing.

[Jeff Anderson]

Andrew McNabb wrote:
> Didn't I merge in your prefix branch a month or two ago? If it's not
> merged, then I'm really confused. :)

Prefix support was for sure not in 0.6b1, nor is it in your currently
published head of your public repo.

> A week or two ago, Matt Gardner noticed that caching was
> over-aggressive, so that when you log in, it shows you the cached page
> from before you logged in. Could this bug explain the behavior you're
> seeing?
>
> Thanks for your testing.
>

I've set my caching backend to dummy, and I'm still seeing the same
behavior. Even if I am logged in, it exhibits the same behavior. The
admin site recognizes my session, but smug still renders non-logged-in
menus over http no matter what. It is also redirecting me to the
anonymous edit page over http instead of directing me to the https edit
form for logged in users.

I've used curl to duplicate this behavior without having a clunky
browser cache taint the behavior.

The only way I can make an edit is to turn off the secure cookie session
option in settings.py, and/or remove the secure session middleware. The
menus and edits work as one would expect, but without the
secure-mindedness of secure session cookies being used.

Thanks!

Jeff Anderson

[Andrew McNabb]

On Sun, Sep 20, 2009 at 09:41:46PM -0600, Jeff Anderson wrote:
> I've set my caching backend to dummy, and I'm still seeing the same
> behavior. Even if I am logged in, it exhibits the same behavior. The
> admin site recognizes my session, but smug still renders non-logged-in
> menus over http no matter what. It is also redirecting me to the
> anonymous edit page over http instead of directing me to the https
> edit form for logged in users.

Hmm. This does look different.

> I've used curl to duplicate this behavior without having a clunky
> browser cache taint the behavior.
>
> The only way I can make an edit is to turn off the secure cookie session
> option in settings.py, and/or remove the secure session middleware. The
> menus and edits work as one would expect, but without the
> secure-mindedness of secure session cookies being used.

Are you using the secure session middleware from Smug, or the original
one? We had to make a one-line change that I can't recall because the
standard version had a bug in it. Could this be the problem?