pyrad is not unicode-aware about pyrad HOT 10 CLOSED

Using str will fail badly if you have any non-ascii characters in your string, so this approach is not ideal. It is probably better to check of unicode instances and encode them using utf-8. I'll see if I can add some tests to show this problem and fix it properly.

from pyrad.

Thanks! Regarding the difference between running via command-line vs. apache, I assume since my declared console encoding is UTF-8 the command-line script is using that by default. Is there a way to influence the default encoding for the script being run via apache? Would something like pep-0263 work I wonder?

#!/usr/bin/python
# -*- coding: utf-8 -*-

I'll give it a shot and see if it works differently for me.

from pyrad.

More likely web.py is doing decoding for you

from pyrad.

I think I have this mostly fixed in the current git tree. The current tree is also almost fully python 3 compatible, which was a nice side benefit of cleaning this up.

from pyrad.

Thanks! I'll test the change today and let you know if I'm still seeing it.

from pyrad.

Did the changes work for you?

from pyrad.

Sorry its taking so long to verify your change. I'm developing and deploying my code on a Debian stable box running python 2.6.6. I don't have a system level package for the python "six" package, so I'm having to put one together now just to run your code. I also had to mod the test*, server and curved scripts to adjust the "exception x as e" syntax to work on my box without errors when installing. I'll let you know as soon as I have something that works.

from pyrad.

Okay, everything appears to work for me. The only oddity I''ve seen is that the radius secret has to be a binary string. It blows up when I feed it a regular unicode string (as I did before), I now have to explicitly encode it to utf-8 to get it to work. If that is what you intended, then its fine by me. Thanks again for this package!

from pyrad.

the "exception x as e" syntax is supported in Python 2.6, so I don't understand why you had to modify that. I have setup Jenkins to test pyrad with Python 2.6, 2.7 and 3.2 and the tests are passing on all three: http://jenkins.simplon.biz/job/pyrad/

The choice to use a binary string for the secret is deliberate: the secret is an 'octet string' in RFC terms, and does not need to be a human readable text.

from pyrad.

I found my error. It looks like Debian Squeeze has both python 2.5 and 2.6 available by default. The python modules are installed for both interpreters during package installation and the errors are coming from python 2.5. I'll dink around with my packaging so it only gets installed for python 2.6. Thanks again!

from pyrad.