patch along the way for that, and some other optimization too.
On Wednesday, October 17, 2012 11:24:26 AM UTC+2, Michele Comitini wrote:
>
> +1
>
> Massimo, is it compressing data also?
>
> mic
>
> 2012/10/17 Massimo Di Pierro >
>
>>
>>
>> On Tuesday, 16 October 2012 17:39:36 UTC-5, Niphlod wrote
+1
Massimo, is it compressing data also?
mic
2012/10/17 Massimo Di Pierro
>
>
> On Tuesday, 16 October 2012 17:39:36 UTC-5, Niphlod wrote:
>>
>> BTW, encrypting and decrypting (on the worst case scenario, 4KB of data)
>> takes 4,7 seconds for 1 million iterations. I'd definitely use encryption
On Tuesday, 16 October 2012 17:39:36 UTC-5, Niphlod wrote:
>
> BTW, encrypting and decrypting (on the worst case scenario, 4KB of data)
> takes 4,7 seconds for 1 million iterations. I'd definitely use encryption
> no matter what if designing a large scale deployment,
>
+1 sessions in cookies w
On Wednesday, October 17, 2012 12:53:33 AM UTC+2, Marin Pranjić wrote:
>
> If encryption is an issue, maybe it should be optional.
>
ehm, 4.7 sec on worst case scenario for 1M repetitions on a single machine
means "wasting" 0,0047 ms per request. Fast responses averages to ~20ms,
so again, wor
If encryption is an issue, maybe it should be optional.
@Nihplod, your posts are very helpful (not just this one) :)
Thanks for your efforts.
--
@all: you should test it before all. Storing session in cookies is achieved
with scalability in mind. It's quite a buzzword on these days, but things
to consider are a lot. Really, a lot.
One thing is saying that sharing a single filesystem among 100 machines
(scalability) is more intensive tha
If web2py actually encrypt sessions, that will take quite some time, and
saving/retrieving sessions can be computing intensive. I think session
data signed and not encrypted is the way to go.
With respect to scalability, the "computation" here is the saving to the
filesystem. This is the burd
and confirmed, you can store a limited amount of data, after that the
session remains the same (~a dict with 80 keys , 10 chars length both for
keys and values)
to reproduce:
import string
def test():
key = session.counter or 0
session['counter'] = key + 1
session[key] = string.lett
goes always in exception, and the bug is that the IV key must be 16 bytes.
secure_dumps is padding the key to 32 (correct) but using key as well for
the IV argument.
On Tuesday, October 16, 2012 1:24:00 PM UTC+2, Massimo Di Pierro wrote:
>
> This is new in trunk and needs to be tested. Add this
I'd go for this if the session is small and does not contain critical
information. So it is good to have this option.
marți, 16 octombrie 2012, 22:27:01 UTC+3, Niphlod a scris:
>
>
> On Tuesday, October 16, 2012 7:46:16 PM UTC+2, VP wrote:
>>
>>
>> I think one advantage of moving session data to
On Tuesday, October 16, 2012 7:46:16 PM UTC+2, VP wrote:
>
>
> I think one advantage of moving session data to the client side is
> scalability. There ought to be a noticeable difference between 100
> processes writing to the same filesytem and these computations moved to the
> client side.
On Tuesday, October 16, 2012 7:42:41 PM UTC+2, VP wrote:
>
>
> It's not meant to be bashing web2py. Massimo said this implementation is
> like Flask. As such, they are cryptographically signed, but not encrypted.
> If that is the case, they might be read but not modified.
>
> yes, but sp
On Tuesday, October 16, 2012 11:39:02 AM UTC-5, Massimo Di Pierro wrote:
>
> Right now you can have or the other. To me it does not make sense to store
> anything client side if you already have to access a pickle object locally.
> You only add overhead and risk of exposing data.
>
>
I think o
On Tuesday, October 16, 2012 11:33:38 AM UTC-5, Niphlod wrote:
>
> did you even try it (or reading the post) before starting bashing around
> :-P ???
> those cookies contains crypted (and signed) data. No user can "read" the
> contents.
>
>
It's not meant to be bashing web2py. Massimo said th
You can do the same in web2py. You can use cache and sessions. The session
you can put where you want. What does not make sense to me is put some
session data in session files and some in cookies. If you have to have the
session files, use them.
On Tuesday, 16 October 2012 11:51:59 UTC-5, Davi
Java PlayFramework! has this as the only default. Using client side cookie
based sessions help create distributed environment easily, as there are no
sessions specific to one server node. They use both client side
cookies for sessions and caches for keeping serverside data.
David
Dne ú
Right now you can have or the other. To me it does not make sense to store
anything client side if you already have to access a pickle object locally.
You only add overhead and risk of exposing data.
On Tuesday, 16 October 2012 10:59:20 UTC-5, VP wrote:
>
> I think cookie-based sessions is great
did you even try it (or reading the post) before starting bashing around
:-P ???
those cookies contains crypted (and signed) data. No user can "read" the
contents.
On Tuesday, October 16, 2012 5:59:20 PM UTC+2, VP wrote:
>
> I think cookie-based sessions is great for many cases. But in some
I think cookie-based sessions is great for many cases. But in some cases,
it might not be desirable as clients can see what might be secret
information.
Why not both?Maybe, two types of sessions, client-side and server-side
sessions. Although both client and server side sessions are mean
All worked fine for me...
Name: session_data_dev_tmobile
Content: "afccd...8B60"
Host: 127.0.0.1
Path: /
Send for: Any type of connection
Expires: At end of session
Name: session_id_dev_tmobile
Content: None
Path: /
Send for: Any type of connection
Expires: At end of session
On Tue, Oct 16, 20
It works fine here. I get two cookies (listed below):
How can we set a longer expiration?
Name: session_id_w2a
Content: None
Domain: localhost
Path: /
Send for: Any kind of connection
Accessible to script: Yes
Created: Tuesday, October 16, 2012 4:51:00 PM
Expires: When the browsing session ends
I'll do ASAP. If the cookie only is used to store session data, I imagine
any webapp using this will hit the 4000 chars limit of cookies, right ?
Did someone tested how much data (let's say, how many keys of a dict
composed by keys 10 characters long with values 10 characters long) can fit
in t
22 matches
Mail list logo