How do I enforce a minimum client version when hosted via httpd

[Stephen Connolly <st...@apache.org>]

I remember reading before about a hack/trick that allows you to ensure that
the client is at least mergeinfo aware when the repository is served via
Apache httpd.

Google is not being co-operative with my attempts to find the Apache HTTPD
directive that makes this magic happen.

IIRC the trick is less than perfect, i.e. it just blocks < 1.5.2 clients
from connecting (though the version limit could be 1.5.0 or 1.5.1 I recall
it being about querying the capabilities of the client and a specific
capability was only introduced in 1.5.1 or 1.5.2) A better trick would allow
blocking clients less than 1.6.13 from connecting ;-)

Anyway, if somebody could point me to the trick it would be much appreciated

-Stephen

Re: How do I enforce a minimum client version when hosted via httpd

[Stephen Connolly <st...@gmail.com>]

That was the trick I was looking for.  Thanks

On 7 October 2010 10:25, Ryan Schmidt <su...@ryandesign.com> wrote:
> On Oct 7, 2010, at 03:29, Stephen Connolly wrote:
>
>> I remember reading before about a hack/trick that allows you to ensure that the client is at least mergeinfo aware when the repository is served via Apache httpd.
>>
>> Google is not being co-operative with my attempts to find the Apache HTTPD directive that makes this magic happen.
>>
>> IIRC the trick is less than perfect, i.e. it just blocks < 1.5.2 clients from connecting (though the version limit could be 1.5.0 or 1.5.1 I recall it being about querying the capabilities of the client and a specific capability was only introduced in 1.5.1 or 1.5.2) A better trick would allow blocking clients less than 1.6.13 from connecting ;-)
>
> There is no Apache directive for this; instead, you can write a clause in your start-commit hook script. From the start-commit.tmpl file created for you in every new repository:
>
>
> #   [1] REPOS-PATH   (the path to this repository)
> #   [2] USER         (the authenticated user attempting to commit)
> #   [3] CAPABILITIES (a colon-separated list of capabilities reported
> #                     by the client; see note below)
> #
> # Note: The CAPABILITIES parameter is new in Subversion 1.5, and 1.5
> # clients will typically report at least the "mergeinfo" capability.
> # If there are other capabilities, then the list is colon-separated,
> # e.g.: "mergeinfo:some-other-capability" (the order is undefined).
>
>
> So if the third parameter passed to your start-commit hook script is empty / nonexistent, you know that client is older than 1.5 and you can take some action, such as denying the commit, if that's what you want to do.
>
>

Re: How do I enforce a minimum client version when hosted via httpd

[Ryan Schmidt <su...@ryandesign.com>]

On Oct 7, 2010, at 03:29, Stephen Connolly wrote:

> I remember reading before about a hack/trick that allows you to ensure that the client is at least mergeinfo aware when the repository is served via Apache httpd.
> 
> Google is not being co-operative with my attempts to find the Apache HTTPD directive that makes this magic happen.
> 
> IIRC the trick is less than perfect, i.e. it just blocks < 1.5.2 clients from connecting (though the version limit could be 1.5.0 or 1.5.1 I recall it being about querying the capabilities of the client and a specific capability was only introduced in 1.5.1 or 1.5.2) A better trick would allow blocking clients less than 1.6.13 from connecting ;-)

There is no Apache directive for this; instead, you can write a clause in your start-commit hook script. From the start-commit.tmpl file created for you in every new repository:


#   [1] REPOS-PATH   (the path to this repository)
#   [2] USER         (the authenticated user attempting to commit)
#   [3] CAPABILITIES (a colon-separated list of capabilities reported
#                     by the client; see note below)
#
# Note: The CAPABILITIES parameter is new in Subversion 1.5, and 1.5
# clients will typically report at least the "mergeinfo" capability.
# If there are other capabilities, then the list is colon-separated,
# e.g.: "mergeinfo:some-other-capability" (the order is undefined).


So if the third parameter passed to your start-commit hook script is empty / nonexistent, you know that client is older than 1.5 and you can take some action, such as denying the commit, if that's what you want to do.

RE: How do I enforce a minimum client version when hosted via httpd

[Jon Foster <Jo...@cabot.co.uk>]

Hi,

Stephen Connolly wrote:
> I remember reading before about a hack/trick that allows you
> to ensure that the client is at least mergeinfo aware when the
> repository is served via Apache httpd.

You can have a start-commit hook.  It can reject commits from clients
that don't have the "mergeinfo" capability.

http://svnbook.red-bean.com/en/1.5/svn.ref.reposhooks.start-commit.html

> A better trick would allow blocking clients less than 1.6.13 from
connecting ;-)

Subversion sends it's version in the User-Agent string.  You can test
that in your Apache config file.  (But this is probably a bad idea
unless it's an internal SVN server that's locked down by corporate
policy).

http://httpd.apache.org/docs/2.2/howto/access.html#env

Bear in mind that some people may not be using the official Subversion
client.

Kind regards,

Jon


**********************************************************************
This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd.

If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone.

Cabot Communications Limited
Verona House, Filwood Road, Bristol BS16 3RY, UK
+44 (0) 1179584232

Co. Registered in England number 02817269

Please contact the sender if you believe you have received this email in error.

**********************************************************************


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________