I am fine with your idea, but we should implement a clear solution.
- remove GeoServerCompositeFilter.CACHE_KEY_IDLE_SECS and refactor the code
- remove GeoServerCompositeFilter.CACHE_KEY_LIVE_SECS and refactor the code
- remove method AuthenticationCache.put(String, String, Authentication,
Integer, Integer) and refactor the code
- add the missing logic to GeoServerDigestAuthentication filter
The idea is to remove the possibility to have individual time out values
for a cache entry. This will make it easier to add cache implementations in
the future.
+1 from here if you want to go this way.
Cheers
Christian
On Wed, Jul 9, 2014 at 6:55 PM, Mauro Bartolomeoli <
mauro.bartolome...@geo-solutions.it> wrote:
> Hi,
>
>
> 2014-07-09 18:23 GMT+02:00 Christian Mueller <
> christian.muel...@os-solutions.at>:
>
> Hi Mauro
>>
>> Sorry for the late reply, I am in holidays at the moment.
>>
>> You asked about the expiration times for individual entries used in
>> GeoServerCompositeFilter.
>> Take a look at GeoServerDigestAuthenticationFilter. Digest authentication
>> uses a secret token derived from the password and avoids sending the
>> password over the network.
>>
>> This token has its own expiration time and the principal has to
>> authenticate again after it expires, independent of the cache. The token
>> expiration time has a higher precedence as the expiration time used by the
>> cache.
>>
>> Example:
>> The cache has expiration times of 50 secs, but the digest authentication
>> filter uses expiration times of 30 secs. In this constellation, a cache
>> entry generated by the digest authentication filter is only valid for 30
>> secs. Using 50 secs for this entry is not correct. Using the cache entry
>> after 40 seconds (as example) simple violates the digest authentication
>> configuration.
>>
>>
> I understood the problem. In my opinion we are mixing concerns in this
> case.
> If the AuthenticationCache is a cache, entries can also expire for other
> reasons than the entry expiration time (for example because the cache is
> full, so some entries have to be evicted before their expiration time).
> I think the digest token expiration should be handled at a higher level,
> and the cache simplified to only act as a cache (in this case we are using
> it also as a storage of expiring items).
>
> Can you think of any way to move digest token expiration handling directly
> into the GeoServerDigestAuthenticationFilter (for example we could do a
> double check of the entry from the cache to verify if it is still valid,
> outside of the cache code)? What do you think? Am I missing something?
>
> Mauro
>
>
> --
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/NWWaa2 for more information.
> ==
>
> Dott. Mauro Bartolomeoli
> @mauro_bart
> Senior Software Engineer
>
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054 Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> -------------------------------------------------------
>
--
DI Christian Mueller MSc (GIS), MSc (IT-Security)
OSS Open Source Solutions GmbH
------------------------------------------------------------------------------
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
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
