Escaping bug exists in Oracle 9.2.0.5 and earlier. It was fixed in
patchset 9.2.0.6 and any later version.
What comes to Oracle official support options for 9.2:
Premier Support Ends: 31-Jul-2007
Extended Support Ends: 30-Jul-2010
If any problem is encountered you're first required to upgrade to
On Dec 22, 12:52 am, Johannes Dollinger
wrote:
> I'd like some more kwargs to Signer and TimestampSigner. Mostly what's
> inhttp://dpaste.com/136418/(except the `separator` kwarg, which was
> a bad idea as it depends on encode()): Signer(serializer=...) and
> TimestampSigner(ttl=...).
The f
On Tue, Dec 22, 2009 at 12:22 AM, Russell Keith-Magee
wrote:
> On Tue, Dec 22, 2009 at 8:00 AM, Simon Willison
> wrote:
>> I've made some changes based on the feedback in this thread:
>>
>> http://github.com/simonw/django/commit/802952bbb8b763e65ee545c6a8f39524b20e147c
>> "Use sha('signer' + sec
On Tue, Dec 22, 2009 at 8:00 AM, Simon Willison wrote:
> I've made some changes based on the feedback in this thread:
>
> http://github.com/simonw/django/commit/802952bbb8b763e65ee545c6a8f39524b20e147c
> "Use sha('signer' + secret_key + salt) to derive the key for use in
> the
> signature() method
Hi Ian,
Ian Kelly wrote:
> Not currently, no. And if I were to put in some work on improving on
> the Oracle backend's support for filtering on TextFields, I would
> concentrate first on fixing the query so that it correctly compares
> the entire TextField and not just the first 4000 characters.
On Tue, Dec 8, 2009 at 1:05 PM, Jeremy Dunck wrote:
> On Tue, Dec 8, 2009 at 12:56 PM, Alex Gaynor wrote:
>
>> This line of reasoning makes 0 sense IMO. Your argument is people
>> provide sub-par patches because they think trunk moves too quickly,
>> and a committer will need to rewrite it
On Dec 22, 1:52 pm, Johannes Dollinger
wrote:
> There's a small bug in b64_decode(), the padding should be
> r = len(s) % 4
> pad = '=' * (r and 4 - r or 0)
Or even simpler:
pad = '=' * (-len(s) % 4)
--
You received this message because you are subscribed to the Google Group
On Tue, Dec 22, 2009 at 12:12 AM, Tobias McNulty wrote:
> http://code.djangoproject.com/ticket/11843
>
> This is a simple fix to a rather bothersome problem; if you need to do
> anything with those hidden inputs in JavaScript there's no way to uniquely
> identify them without extending the widget
>
> (1)
> http://code.djangoproject.com/attachment/ticket/12403/syndication-views-4.diff(Why
> aren't my diffs showing? Are they too large for trac?)
>
>
It's likely the six of these:
\ No newline at end of file
in the diff.
Karen
--
You received this message because you are subscribed to the
There's a small bug in b64_decode(), the padding should be
r = len(s) % 4
pad = '=' * (r and 4 - r or 0)
I'd like some more kwargs to Signer and TimestampSigner. Mostly what's
in http://dpaste.com/136418/ (except the `separator` kwarg, which was
a bad idea as it depends on enco
On 21 Dec 2009, at 20:06, Luke Plant wrote:
>> I've documented it in some detail in the release notes. Is this
>> painstaking enough?
>
> Unless I'm missing something, it's not nearly there (but some of this
> may be the 'formal stuff' that Jacob doesn't mind being missing for
> now).
>
> Firs
On Dec 8, 3:23 am, Rick Yazwinski wrote:
> I think that this may be too simplified:
> protocol = getattr(settings, "PROTOCOL", "http")
> domain = Site.objects.get_current().domain
> port = getattr(settings, "PORT", "")
>
> Many sites put load balancers and https hardward ac
I've made some changes based on the feedback in this thread:
http://github.com/simonw/django/commit/802952bbb8b763e65ee545c6a8f39524b20e147c
"Use sha('signer' + secret_key + salt) to derive the key for use in
the
signature() method, addressing feedback from the django-developers
list"
The default
On Mon, Dec 21, 2009 at 11:12 AM, Tobias McNulty wrote:
> http://code.djangoproject.com/ticket/11843
>
> This is a simple fix to a rather bothersome problem; if you need to do
> anything with those hidden inputs in JavaScript there's no way to uniquely
> identify them without extending the widget
Am 15.12.2009 um 19:57 schrieb Andrew Durdin:
> On Dec 14, 11:00 pm, ab wrote:
>>> `wrap_and_raise()` will appear in the traceback, `raise
>>> wrap_exception(SomeException())` would be cleaner.
>>
>> I like that
>
> But you must use the three-argument `raise` statement to supply your
> own trace
On Mon, Dec 21, 2009 at 3:25 PM, Mat Clayton wrote:
> Hey all,
>
> Now that Email Backend's have landed, and we finally got round to rolling it
> out in to production, I discovered small niggle with our deployment.
> Currently we use an external email provider to deliver email, and the
> backends
>> * The DEFAULT_TIME_INPUT_FORMATS strings have been removed from the
>> forms/fields.py module. I know they are no longer required, but they
>> were previously public symbols. I suspect we need to leave them in,
>> but mark them as deprecated in docs. Ideally, we would be raising
>> deprecation w
Hey all,
Now that Email Backend's have landed, and we finally got round to rolling it
out in to production, I discovered small niggle with our deployment.
Currently we use an external email provider to deliver email, and the
backends has allowed us to do this fantastically. However when an error
o
Hi Russell,
Thanks for the review :)
> * The DEFAULT_TIME_INPUT_FORMATS strings have been removed from the
> forms/fields.py module. I know they are no longer required, but they
> were previously public symbols. I suspect we need to leave them in,
> but mark them as deprecated in docs. Ideally, w
On Monday 21 December 2009 17:20:33 Ben Firshman wrote:
> > * What is going to happen to feeds.Feed? Is it deprecated or
> > not? (there is no PendingDeprecationWarning AFAICS).
> > I for one have a lot of code that uses feeds.Feed directly,
> > bypassing the 'high level' framework that provide
On Mon, Dec 21, 2009 at 4:44 AM, Jani Tiainen wrote:
> On Mon, 2009-12-21 at 02:42 -0700, Ian Kelly wrote:
>> Not currently, no. And if I were to put in some work on improving on
>> the Oracle backend's support for filtering on TextFields, I would
>> concentrate first on fixing the query so that
On 21 Dec 2009, at 12:29, Luke Plant wrote:
> On Sunday 20 December 2009 13:04:00 Ben Firshman wrote:
>> Okay, I've updated the ticket with a new patch:
>>
>> http://code.djangoproject.com/ticket/12403
>>
>> I wasn't sure on the extent of the depreciation warnings required,
>> but hopefully that's
http://code.djangoproject.com/ticket/11843
This is a simple fix to a rather bothersome problem; if you need to do
anything with those hidden inputs in JavaScript there's no way to uniquely
identify them without extending the widget and creating your own render()
(not to mention the fact that it's
On Mon, Dec 21, 2009 at 10:46 AM, Simon Willison
wrote:
> On Dec 21, 2:22 pm, Marty Alchin wrote:
>> Looking over Simon's patch for signed cookies, I noticed that yet
>> another feature needs to write its own "load a backend from a setting"
>> function.
>
> Yup - and as I copied and pasted it fro
On Dec 21, 2:22 pm, Marty Alchin wrote:
> Looking over Simon's patch for signed cookies, I noticed that yet
> another feature needs to write its own "load a backend from a setting"
> function.
Yup - and as I copied and pasted it from somewhere else I thought
exactly the same thing. Is this kind o
On Dec 21, 2:40 pm, Russell Keith-Magee
wrote:
> * I'm not sure I like this being in django.utils. To me, it feels
> like something that should be in django.core - along with caching,
> serialization, etc, signing is a core piece of functionality that a
> website will need to implement. django.ut
On Mon, Dec 21, 2009 at 10:39 PM, Jeremy Dunck wrote:
> On Mon, Dec 21, 2009 at 8:22 AM, Marty Alchin wrote:
> ...
>> django.contrib.auth.load_backend()
>> django.core.files.storage.get_storage_class()
>> django.template.loader.find_template_loader()
>> django.db.load_backend()
>
> Also, django.c
On Mon, Dec 21, 2009 at 7:43 PM, Simon Willison wrote:
> I've uploaded the patch for adding signing and signed cookies to
> Django:
>
> http://code.djangoproject.com/attachment/ticket/12417/ticket12417.diff
>
> You can also read the documentation directly on my GitHub branch:
>
> http://github.com
On Mon, Dec 21, 2009 at 8:22 AM, Marty Alchin wrote:
...
> django.contrib.auth.load_backend()
> django.core.files.storage.get_storage_class()
> django.template.loader.find_template_loader()
> django.db.load_backend()
Also, django.core.cache.get_cache
--
You received this message because you are
Looking over Simon's patch for signed cookies, I noticed that yet
another feature needs to write its own "load a backend from a setting"
function. A quick search of the codebase shows at least four other
instances of this behavior (shown below), and it seems it's only going
to get more common going
On Mon, Dec 21, 2009 at 8:00 AM, Luke Plant wrote:
> Rather than use 'settings.SECRET_KEY' as the default HMAC key,
> shouldn't we add a prefix so that any usage of SECRET_KEY can't be
> (potentially) used to attack other usages? We discussed this a while
> back. The new messages system uses:
>
Ok, thanks for letting me know. I will bump or repost after the
release if this discussion doesn't catch on, and if my enthusiasm
hasn't worn out by then ;)
On Dec 21, 1:59 pm, Russell Keith-Magee
wrote:
> On Mon, Dec 21, 2009 at 9:37 PM, hejsan wrote:
> > I know this has been discussed and in m
On Mon, Dec 21, 2009 at 9:37 PM, hejsan wrote:
> I know this has been discussed and in most threads I've found it has
> been disregarded with comments like: "Just use a 3rd party app" or
> "just use the sites-framework" but I think there are definetly
> advantages to having this an included featur
I know this has been discussed and in most threads I've found it has
been disregarded with comments like: "Just use a 3rd party app" or
"just use the sites-framework" but I think there are definetly
advantages to having this an included feature. So here goes again:
I was very surprised to find tha
On Monday 21 December 2009 11:43:19 Simon Willison wrote:
> The code has documentation and unit tests. The documentation isn't
> 100% complete - I need to improve the explanation of what signing
> is and why it is useful and document the new COOKIE_SIGNER_BACKEND
> setting which allows users to
On Sunday 20 December 2009 13:04:00 Ben Firshman wrote:
> Okay, I've updated the ticket with a new patch:
>
> http://code.djangoproject.com/ticket/12403
>
> I wasn't sure on the extent of the depreciation warnings required,
> but hopefully that's the sort of thing needed.
>
> Thanks,
>
> Ben
On Mon, 2009-12-21 at 02:42 -0700, Ian Kelly wrote:
> On Sun, Dec 20, 2009 at 11:25 PM, Mario Briggs
> wrote:
> >> This is known. The Oracle notes [1] mention that TextFields cannot be
> >> indexed. Since Oracle requires indexes for unique columns, this also
> >> means they cannot be unique, al
I've uploaded the patch for adding signing and signed cookies to
Django:
http://code.djangoproject.com/attachment/ticket/12417/ticket12417.diff
You can also read the documentation directly on my GitHub branch:
http://github.com/simonw/django/blob/signed/docs/topics/signing.txt
http://github.com/
On Sun, Dec 20, 2009 at 11:25 PM, Mario Briggs wrote:
>> This is known. The Oracle notes [1] mention that TextFields cannot be
>> indexed. Since Oracle requires indexes for unique columns, this also
>> means they cannot be unique, although we should probably make that
>> explicit. It may also b
39 matches
Mail list logo
