Re: HMAC_KEY server based

> Il giorno 09/lug/2014, alle ore 19:29, Irmen de Jong <[email protected]> ha scritto:
> 
> On 9-7-2014 17:55, Giovanni Porcari wrote:
>> Hi Irmen
>> 
>> some month ago i asked you about the possibility to have a different HMAC_KEY 
>> for each server and not just one based on PYRO config.
>> 
>> I sent you also a possible way to implement it but at this time you was 
>> not sure about the future of HMAC_key feature.
> 
> Yes I remember this.
> 
>> I think that you use pyro in many server and you have to connect to
>> more than one in the same context it is not possible unless you use
>> the same hmac_key.
>> 
>> Do you have now some more thoughts about this problem ?
> 
> To be honest, I haven't given it much thought. My priorities lie elsewhere at this time.
> However, a few months ago I was talking about perhaps replacing the HMAC mechanism by a
> newer more general security mechanism. That hasn't happened yet and I don't see that
> happening very soon either, so the simpler approach you took in your proposal at the
> time may actually be the way to go for the time being. I do agree that the limitation of
> just a single global HMAC key across all your client proxies is not very practical.
> 
> It would be awesome if you could perhaps update your code changes for the current source
> and even more awesome if you could include a few unit tests as well, and submit it as a
> git pull request?
> 
> I can then perhaps sneak it into the next release 4.27 or the one after.

Ok. I will try to find some time to do it and i will send the pull request :) 


> 
> 
> 
>> We created, using pyro4, a session manager to replace the previous
>> memcached backend. It works very well and in many months of 
>> work in many server we never had a problem.
> 
> Quite interesting, never thought Pyro4 would compete somehow with the likes of
> memcached. What made you switch? Memcached should be a very high performing distributed
> cache, how can Pyro4 provide you with something similar?
> 

The short answer is : memcache is very fast but 'stupid'.
It is just a shared dict of pickled objects.
We had to handle concurrency and locks. Pain.

With pyro we use the multiplex server so no need of
concurrency and locks and  any call to the pyro store (register)
can do very complex task, changing the state of the page
store in many locations. It is just a dream. 
Fast and with a complete control of the work.

The long story (if you like to see it) is here:

 https://github.com/genropy/genropy/blob/master/gnrpy/gnr/web/gnrdaemonhandler.py

it is a main process and it create a subprocess for each site that handle the site register:
   
https://github.com/genropy/genropy/blob/master/gnrpy/gnr/web/gnrwsgisite_proxy/gnrsiteregister.py

Thank you again :)

G
------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft