Re: [fossil-users] Fossil social networking

[Paul Ruizendaal]

> Can you link me some info on the hooks?  I didn't need them for the
social
> networking stuff, but something like server-side scripting with scripts
in
> the repository would be very nice.  TH1 is good for templating, but
> personally, I'd like a "full" language -- a complete TCL or Lua or
> something
> like that.

I'm working on a small, but full javascript 1.5 implementation which
should be ready this Summer. It's about 7.000 lines of C and compiles to a
140kb binary on x86. That's substantially larger than TH1 (which is a 45kb
or so binary). It might be a nice addition to Fossil, but I think that
Richard might prefer TCL.

That being said, I'm opposed to bloat and function creep in Fossil.
Perhaps what is needed is a small companion to Fossil that acts as a hub
server. That companion could be a webserver / sqlite / javascript combo,
which either reads the database files direct, or calls out to Fossil to
perform its operations.

Paul
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil social networking

[Alaric Snell-Pym]

On 03/29/11 10:16, Paul Ruizendaal wrote:

> That being said, I'm opposed to bloat and function creep in Fossil.
> Perhaps what is needed is a small companion to Fossil that acts as a hub
> server. That companion could be a webserver / sqlite / javascript combo,
> which either reads the database files direct, or calls out to Fossil to
> perform its operations.

Hrm. Why embed a language for hooks at all? svn/git/etc seem to have
managed without... this makes hooks platform-specific (shell scripts are
fine for Unix users, less fine on Windows), but as the hooks would
presumably be repo-specific rather than part of the global state, is
that a problem?

>
> Paul
>

ABS

--
Alaric Snell-Pym
http://www.snell-pym.org.uk/alaric/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Post-commit hook

[Antoine Chavasse]

Sorry for the email necromancy, but since there are talks about post
commit hooks again and as it seems it would generally be a useful
feature, I remembered about the roadblock that Richard encountered
that hadn't received a good anwser as far as I remember:

On Mon, Jan 3, 2011 at 12:58 PM, Richard Hipp  wrote:
>
> I've got a  plan for a better way to do various "hooks", but in order for it
> to work cross-platform, I need code that will start a background process on
> windows.  By "background" process, I mean a process that will continue
> running even after its parent process exits or is killed.  If any windows
> experts out there can explain to me how to do that, or provide sample code,
> that will expedite getting the "hook" logic into the Fossil trunk.

So I looked into the win32 process creation APIs and played with them
on a windows box. It turns out that CreateProcess
(http://msdn.microsoft.com/en-us/library/ms682425%28v=vs.85%29.aspx)
offers a range of options to run a process in a different console
window, without a console, or with its stdin / stdout bound to
arbitrary handles.

If you look in the creation flags you can pass to CreateProcess
(http://msdn.microsoft.com/en-us/library/ms684863(v=vs.85).aspx ), you
can give CREATE_NEW_CONSOLE to create a new console window for the new
process, CREATE_NO_WINDOW to have no window created for it, or
DETACH_PROCESS to just detach the process (which seems different than
CREATE_NO_WINDOW, I think it's for the case where you want to provide
your own file handle for stdin and stdout, which I didn't try).

Those three flags are mutually exclusive.

Below is a quick test program I made that launch the file you give it
on the command line. I used a small .bat file echoing things in a loop
in both the console and a file for testing that I launched with it.

With flags set at zero, predictably the script stopped running when I
closed the console (but kept running after the program ended).

With "CREATE_NEW_CONSOLE", it ran in a new, separate console window
that kept running even when the original console was closed.

With "CREATE_NO_WINDOW", it ran silently (the file kept growing) and
kept running after closing the console (I had to kill it through the
task manager).

With "DETACHED_PROCESS", nothing happened. Obviously the script simply
couldn't run without any form of input/output, but I suspect this is
the option to use when you want to provide your own file handles to
redirect stdin and stdout for the new process (in the STARTUPINFO
structure).


#include "stdafx.h"

int _tmain(int argc, _TCHAR* argv[])
{
//ShellExecute( NULL, "open", argv[1], NULL, NULL, 0 );
STARTUPINFO si;
PROCESS_INFORMATION pi;

ZeroMemory( &si, sizeof(si) );
si.cb = sizeof(si);
ZeroMemory( &pi, sizeof(pi) );

CreateProcess( NULL,   // No module name (use command line)
argv[1],// Command line
NULL,   // Process handle not inheritable
NULL,   // Thread handle not inheritable
FALSE,  // Set handle inheritance to FALSE
CREATE_NO_WINDOW,  // No creation flags
NULL,   // Use parent's environment block
NULL,   // Use parent's starting directory
&si,// Pointer to STARTUPINFO structure
&pi );   // Pointer to PROCESS_INFORMATION structure

return 0;
}
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Sub-repositories?

[Richard Hipp]

On Mon, Mar 28, 2011 at 10:36 PM, Michael Richter wrote:

> I just saw an intriguing message in the timeline.  "Leaf: Merge the
> sub-repo capability into trunk."  I can't find anywhere in the help, the
> fossil docs nor in the wiki that talks about this.  How does one use this
> new sub-repo capability?
>

Sub-repositories is nothing more than the opportunity to create
single-signon for two or more separate repositories at a single website.

We have an SQLite Consortium member who is using several proprietary SQLite
extensions.  Previously, they had a separate login for the repository of
each extension.  Password management was becoming an issue for them, so they
requested a unified private website, with a wiki, that gives them access to
all of the extensions all at once.  Subrepositories provide this.

Suppose the subrepos are named abc.fossil, def.fossil, and ghi.fossil.  The
name of the main repository is xyz.fossil.  All the repositories files live
in the same directory, say.  Suppose the xyz.fossil repository is accessible
as:  https://domain/path/to/xyz.  Then you create entries in the xyz.fossil
SQLite database like this:

INSERT INTO config(name,value) VALUES('subrepo:abc','user1:abc.fossil');
INSERT INTO config(name,value) VALUES('subrepo:def','user2:def.fossil');
INSERT INTO config(name,value)
VALUES('subrepo.lmnop','user3:ghi.fossil');

Those entries activate subrepositories so that users can log once to xyz but
access the other repositories using URLs like:

https://domain/path/to/xyz/abc/timeline
https://domain/path/to/xyz/def/timeline
https://domain/path/to/xyz/lmnop/timeline

The access permissions to the subrepositories are those for user1, user2,
and user3, respectively.

The client company has many individuals at several office locations who all
need access to the subrepositories.  But on the subrepos for the proprietary
SQLite extensions, we only have a single login for the client as a whole.
The subrepo mechanism allows the various users at the client company to each
have their own username and password but still share access to the subrepos
using a unified login name.

We only allow the client "Reader" capabilities when accessing the subrepos.
But for the main repo that contains the project wiki and other resources,
the client has full "Setup" capability so that they can do whatever they
want on their private repo without accidentally making undesirable changes
to the subrepos.


>
> --
> "Perhaps people don't believe this, but throughout all of the discussions
> of entering China our focus has really been what's best for the Chinese
> people. It's not been about our revenue or profit or whatnot."
> --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra.
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>


-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] skin builder

[Alexandre Sénéchal]

Hi,

This feature is very attractive and would be very useful in one of my repos.
Any instructions on how to import it and customize it for my repo?

Best regards,
Alexandre Sénéchal

On Tue, Mar 15, 2011 at 2:03 PM, Kevin Greiner  wrote:

>
> On Tue, Mar 15, 2011 at 1:35 PM, Federico Ramallo wrote:
>
>>
>> Also what do you think about the improved table? includes sorting,
>> searchin, grouping, etc
>>
>
> The sorting is very nice and the grouping too. Would it be feasible to make
> the "Key" at the top filter the table when clicked? Or, at least, scroll to
> the relevant section?
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>


-- 
AlexS
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil social networking

[Bill Burdick]

On Tue, Mar 29, 2011 at 4:32 AM, Alaric Snell-Pym
wrote:

> On 03/29/11 10:16, Paul Ruizendaal wrote:
>
> > That being said, I'm opposed to bloat and function creep in Fossil.
> > Perhaps what is needed is a small companion to Fossil that acts as a hub
> > server. That companion could be a webserver / sqlite / javascript combo,
> > which either reads the database files direct, or calls out to Fossil to
> > perform its operations.
>
> Hrm. Why embed a language for hooks at all? svn/git/etc seem to have
> managed without... this makes hooks platform-specific (shell scripts are
> fine for Unix users, less fine on Windows), but as the hooks would
> presumably be repo-specific rather than part of the global state, is
> that a problem?
>
> >
> > Paul
> >
>
> ABS


Functionality-wise, call-out hooks are OK for some things but a good,
embedded scripting language is a simple way to do tightly integrated,
cross-platform Fossil extensions, like Mercurial's plugins.  If that was
available, people wouldn't always have to change the binary to add
functionality that requires tight integration.  You can make tiny mods to
Fossil along the way to expose needed functionality -- no need to build a
giant extension framework ahead of time.

Also, Fossil is already a file system -- an embedded scripting language
could run scripts stored as Fossil artifacts directly, so you wouldn't have
to use the host file system to manage your scripts (and then maybe use yet
another repository to version-control your hooks).  Lua and TCL are both
good scripting languages; these days, Lua looks to be about 1/5 the size of
TCL.


Bill
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Client certificates and ticket 727af73f46

[Jan Danielsson]

Hello,

   I've added support for supplying CA certificates and client
certificates/keys to fossil on the jan-clientcert branch. This will
allow fossil to be used against https servers which require full
client/CA certificate chain verification.

   Unfortunately, I've stepped off the path a little with regards to
prior art: I'm using environment variables.

   The way it works is like this:
   $ FOSSIL_CAFILE=/etc/ssl/public/ca.crt
FOSSIL_CCERT=~/.certs/mycompany.crt FOSSIL_CKEY=~/.certs/mycompany.key
fossil clone https://repos.mycompany.com/secret/projectX x.fossil

   (FOSSIL_CAPATH is supported too)

   $ fossil sync -R x.fossil

   ..in other words: the variables are cached in the global
configuration in a somewhat similar way to the server certificate
(there's an url association, but it differs in that it only stores the
references, rather than the actual certificates/keys).

   The reason I used environment variables was that I couldn't figure
out a good interface for managing certificates/keys. Also I was slightly
lazy, because I needed the feature fast. Suggestions on better (more
fossil-like) solutions are welcome.

   Anyone affected by ticket 727af73f46 ("ssl: on "pull -R repo", gets
ssl certificate again, asks to accept a/y/N",
http://www.fossil-scm.org/index.html/info/727af73f46) but who doesn't
use client certificates could try my branch and only supply
FOSSIL_CAFILE or FOSSIL_CAPATH, and see if it stops asking about
accepting the certificate. Please let me know about the results.

   Finally, a known limitation is that it doesn't support password
protected client keys. This is on my ToDo-list.

-- 
Kind regards,
Jan Danielsson




signature.asc
Description: OpenPGP digital signature
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Error: not authorized to read / write

[sky5walk]

Hi,
Another new user dumb question...

I created a local and cloned repository with 2 users/passwords that
have all privileges checked.

autosync is OFF

--- Command ---
fossil pull t:\myrepo.fossil

--- Returns ---
Bytes  Cards  Artifacts Deltas
Sent: 130  1  0  0
Error: not authorized to read
Received:  64  1  0  0
Total network traffic: 240 bytes sent, 0 bytes received
--- End ---


Is there a wrong bit flipped somewhere?

I browsed the tickets but how do I review the solution?

9ce0321b54   2009-05-22 08:05:11 IncidentClosed  fossil 
push -
server says: not authorized to write


Note: I was able to pull and push with repositories setup using
default conditions only.


Thanks,
Steve
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Sub-repositories?

[Michael Richter]

Thanks, Richard.  That cleared things up.

On 29 March 2011 20:25, Richard Hipp  wrote:



-- 
"Perhaps people don't believe this, but throughout all of the discussions of
entering China our focus has really been what's best for the Chinese people.
It's not been about our revenue or profit or whatnot."
--Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Error: not authorized to read / write

[sky5walk]

Got it...

When I uncheck Admin - Access ...
[ ] Require password for local access

...I am now able to push and pull.

Thanks,
Steve

On Tue, Mar 29, 2011 at 11:42 AM,   wrote:
> Hi,
> Another new user dumb question...
>
> I created a local and cloned repository with 2 users/passwords that
> have all privileges checked.
>
> autosync is OFF
>
> --- Command ---
> fossil pull t:\myrepo.fossil
>
> --- Returns ---
>                Bytes      Cards  Artifacts     Deltas
> Sent:             130          1          0          0
> Error: not authorized to read
> Received:          64          1          0          0
> Total network traffic: 240 bytes sent, 0 bytes received
> --- End ---
>
>
> Is there a wrong bit flipped somewhere?
>
> I browsed the tickets but how do I review the solution?
>
> 9ce0321b54       2009-05-22 08:05:11     Incident        Closed          
> fossil push -
> server says: not authorized to write
>
>
> Note: I was able to pull and push with repositories setup using
> default conditions only.
>
>
> Thanks,
> Steve
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Sub-repositories?

[Nolan Darilek]

So it sounds like this might be a way to support the use case for which 
I proposed index.fossil last week, correct? That is, I could have a 
default repository served up at the root of the domain, with the wiki 
and other links referencing its pages, but add sub-repositories for the 
various spin-off projects. Is this accurate?


On 03/29/2011 10:45 AM, Michael Richter wrote:
> Thanks, Richard.  That cleared things up.
>
> On 29 March 2011 20:25, Richard Hipp  wrote:
>
>
>
>
>
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Summary of i18n status, for inclusion into Fossil introduction wiki

[Clifford Caoile]

Hello fossil-users:

I was intrigued with Fossil after reading the enthusiastic LWN article
[1]. Unfortunately I do not see any summary about Fossil and
Internationalization (i18n). Let me contribute a summary which can be
used on the Fossil wiki.

---8<---
Fossil and Internationalization (i18n)

Current as of version
[http://www.fossil-scm.org/fossil/info/84e755e213|84e755e213]
(2011-03-16)

Content

Fossil does not modify or re-encode your content.
For display with the internal web server, Fossil does not enforce any
encoding, and leaves the encoding interpretation up to your browser.
(e.g. no encoding specified in the html or doctype tags)

File names

Fossil does not attempt to store the encoding of the file name. File
names are regenerated as is with no re-encoding.

When working with Windows, Fossil will use the national code page for
the encoding and not UTF-8.For example, for Japanese file names, the
encoding will be Windows-31J (CP932) and not even UTF-16, due to the
usage of mingw. In this respect, Fossil is not cross-platform, even
between different Windows localizations. See ticket [d22946aa0c].

User Interface

User interface is the command line and web page, and built-in help is
provided in English, only. No other languages are supported.

Commit message

Same as Content.
---8<---

I have only spent a couple of hours with Fossil so please correct my
mistaken observations.

[1] https://lwn.net/Articles/433843/

Best regards,
Clifford Caoile
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil on IIS

[Tony Perovic]

This is driving me nuts..

I created a CGI file for my repository on the server:

Test.cgi:

!#\Program Files\Fossil\Fossil.exe
repository: C:\Projects\Test\Test.fossil

I configured IIS to send *.cgi requests to Fossil.exe then pointed my browser 
to:

http://myserver/Projects/Test/Test.cgi

I get an unformatted web page (no logo, no css). Snooping with Wireshark shows 
this exchange:

Request:

GET /Projects/Test/Test.cgi HTTP/1.1
Host: myserver
Connection: keep-alive
Cache-Control: max-age=0
Accept: 
application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/534.10 
(KHTML, like Gecko) Chrome/8.0.552.224 Safari/534.10
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

Reponse:

HTTP/1.1 200 OK
Cache-Control: no-cache, no-store
Content-Length: 1360
Content-Type: text/html; charset=utf-8
Server: Microsoft-IIS/6.0
Date: Tue, 29 Mar 2011 14:49:39 GMT



Unnamed Fossil Project: Home

...



  

  
  Unnamed Fossil ProjectHome
  Not logged in

.


Request:

GET /Projects/Test/Test.cgi/style.css?default HTTP/1.1
Host: myserver
Connection: keep-alive
Referer: http://myserver/Projects/Test/Test.cgi
Cache-Control: max-age=0
Accept: text/css,*/*;q=0.1
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/534.10 
(KHTML, like Gecko) Chrome/8.0.552.224 Safari/534.10
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

Reponse:

HTTP/1.1 200 OK


Unnamed Fossil Project: Home
...


Request:

GET / Projects/Test/Test.cgi/logo HTTP/1.1
Host: myserver
Connection: keep-alive
Referer: http://myserver/Projects/Test/Test.cgi
Cache-Control: max-age=0
Accept: text/css,*/*;q=0.1
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/534.10 
(KHTML, like Gecko) Chrome/8.0.552.224 Safari/534.10
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

Reponse:

HTTP/1.1 200 OK


Unnamed Fossil Project: Home
...


Yeah, that's right; I got the home page again and again. By trial and error I 
found that the requests should be:

GET /style.css?default HTTP/1.1
GET /logo HTTP/1.1

It seems that Fossil uses the PATH_INFO to construct its reply in CGI mode. I 
achieved the correct results by writing a Perl script that strips the 
SCRIPT_NAME portion from the PATH_INFO environment variable before invoking 
Fossil:

$path = $ENV{"PATH_INFO"};
$script = $ENV{"SCRIPT_NAME"};

if ($path =~ m/^$script/) { # PATH_INFO starts with SCRIPT_NAME?
$ENV{"PATH_INFO"} = substr($path, length($script));
}

All Fossil / CGI requests must be processed through this Perl script. Thus, I 
concluded, Fossil/CGI cannot possibly work on Windows/IIS without scripting.

Q: Is this correct? Am I missing something?

In fact, given the above analysis, it shouldn't work in Linux either, yet, (I 
assume) it does.

Q: Can somebody please explain what is or isn't happening in Linux that is or 
isn't happening in Windows/IIS?

Tony Perovic
Compumation, Inc.

From: fossil-users-boun...@lists.fossil-scm.org 
[mailto:fossil-users-boun...@lists.fossil-scm.org] On Behalf Of Tony Perovic
Sent: Tuesday, March 01, 2011 3:58 PM
To: 'fossil-users@lists.fossil-scm.org'
Subject: [fossil-users] Fossil on IIS

Anybody get Fossil working as a "CGI script" on Microsoft Server 2003 / IIS?

I'm trying to access multiple repositories with one script as described at:
http://www.fossil-scm.org/index.html/doc/trunk/www/server.wiki

Learned more than I ever wanted to know about IIS/CGI/Scripting.

[cid:image001.jpg@01CBEE05.FBC6AD60]

TONY PEROVIC

tpero...@compumation.com
www.compumation.com

205 W. Grand Ave., Ste. 121
Bensenville, IL  60106
630-860-1921  Phone
630-860-1928  Fax


<>___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil on IIS

[Richard Hipp]

On Tue, Mar 29, 2011 at 12:40 PM, Tony Perovic wrote:

>  This is driving me nuts……
>
>
>
> I created a CGI file for my repository on the server:
>
>
>
>
> It seems that Fossil uses the PATH_INFO to construct its reply in CGI mode.
> I achieved the correct results by writing a Perl script that strips the
> SCRIPT_NAME portion from the PATH_INFO environment variable before invoking
> Fossil:
>
>
>
> $path = $ENV{"PATH_INFO"};
>
> $script = $ENV{"SCRIPT_NAME"};
>
>
>
> if ($path =~ m/^$script/) { # PATH_INFO starts with SCRIPT_NAME?
>
> $ENV{"PATH_INFO"} = substr($path, length($script));
>
> }
>
>
>
> All Fossil / CGI requests must be processed through this Perl script. Thus,
> I concluded, Fossil/CGI cannot possibly work on Windows/IIS without
> scripting.
>

Fossil assumes that PATH_INFO and SCRIPT_NAME are set up as described in
RFC3875.  If what you say is correct, ISS appears not to follow RFC3875 and
hence does not really support CGI, but rather something that is merely
CGI-like.



>
>
> Q: Is this correct? Am I missing something?
>
>
>
> In fact, given the above analysis, it shouldn’t work in Linux either, yet,
> (I assume) it does.
>

The main Fossil website (http://www.fossil-scm.org/) is just an instance of
Fossil running on a Linux box as CGI.   See
http://www.fossil-scm.org/fossil/doc/trunk/www/selfhost.wiki for additional
information, including the scripts used to enable CGI on the various Fossil
mirrors.


>
>
> Q: Can somebody please explain what is or isn’t happening in Linux that is
> or isn’t happening in Windows/IIS?
>

Reminds me of a haiku I read years ago:

Yesterday it worked.
Today it is not working.
Windows is like that.


>
>
> Tony Perovic
>
> Compumation, Inc.
>   --
>
> *From:* fossil-users-boun...@lists.fossil-scm.org [mailto:
> fossil-users-boun...@lists.fossil-scm.org] *On Behalf Of *Tony Perovic
> *Sent:* Tuesday, March 01, 2011 3:58 PM
>
> *To:* 'fossil-users@lists.fossil-scm.org'
> *Subject:* [fossil-users] Fossil on IIS
>
>
>
> Anybody get Fossil working as a “CGI script” on Microsoft Server 2003 /
> IIS?
>
>
>
> I’m trying to access multiple repositories with one script as described at:
>
> http://www.fossil-scm.org/index.html/doc/trunk/www/server.wiki
>
>
>
> Learned more than I ever wanted to know about IIS/CGI/Scripting.
>
>
>
>  *TONY PEROVIC*
>
>
>
> tpero...@compumation.com
>
> www.compumation.com
>
> 205 W. Grand Ave., Ste. 121
>
> Bensenville, IL  60106
>
> 630-860-1921  Phone
>
> 630-860-1928  Fax
>
>
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>


-- 
D. Richard Hipp
d...@sqlite.org
<>___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil on IIS

[Tony Perovic]

>From RFC3875 Section 4.1,5:


The PATH_INFO variable specifies a path to be interpreted by the CGI

script.  It identifies the resource or sub-resource to be returned by

the CGI script, and is derived from the portion of the URI path

hierarchy following the part that identifies the script itself.


So, basically, my Perl script is taking a non-compliant IIS/CGI PATH_INFO and 
making it compliant.

Microsoft sucks.

Hopefully, my efforts will help the next poor guy trying to configure Fossil on 
IIS.

Thank you,
Tony Perovic
Compumation, Inc.

From: fossil-users-boun...@lists.fossil-scm.org 
[mailto:fossil-users-boun...@lists.fossil-scm.org] On Behalf Of Richard Hipp
Sent: Tuesday, March 29, 2011 12:38 PM
To: fossil-users@lists.fossil-scm.org
Subject: Re: [fossil-users] Fossil on IIS


On Tue, Mar 29, 2011 at 12:40 PM, Tony Perovic 
mailto:tpero...@compumation.com>> wrote:
This is driving me nuts..

I created a CGI file for my repository on the server:


It seems that Fossil uses the PATH_INFO to construct its reply in CGI mode. I 
achieved the correct results by writing a Perl script that strips the 
SCRIPT_NAME portion from the PATH_INFO environment variable before invoking 
Fossil:

$path = $ENV{"PATH_INFO"};
$script = $ENV{"SCRIPT_NAME"};

if ($path =~ m/^$script/) { # PATH_INFO starts with SCRIPT_NAME?
$ENV{"PATH_INFO"} = substr($path, length($script));
}

All Fossil / CGI requests must be processed through this Perl script. Thus, I 
concluded, Fossil/CGI cannot possibly work on Windows/IIS without scripting.

Fossil assumes that PATH_INFO and SCRIPT_NAME are set up as described in 
RFC3875.  If what you say is correct, ISS appears not to follow RFC3875 and 
hence does not really support CGI, but rather something that is merely CGI-like.



Q: Is this correct? Am I missing something?

In fact, given the above analysis, it shouldn't work in Linux either, yet, (I 
assume) it does.

The main Fossil website (http://www.fossil-scm.org/) is just an instance of 
Fossil running on a Linux box as CGI.   See 
http://www.fossil-scm.org/fossil/doc/trunk/www/selfhost.wiki for additional 
information, including the scripts used to enable CGI on the various Fossil 
mirrors.


Q: Can somebody please explain what is or isn't happening in Linux that is or 
isn't happening in Windows/IIS?

Reminds me of a haiku I read years ago:

Yesterday it worked.
Today it is not working.
Windows is like that.


Tony Perovic
Compumation, Inc.

From: 
fossil-users-boun...@lists.fossil-scm.org
 
[mailto:fossil-users-boun...@lists.fossil-scm.org]
 On Behalf Of Tony Perovic
Sent: Tuesday, March 01, 2011 3:58 PM

To: 
'fossil-users@lists.fossil-scm.org'
Subject: [fossil-users] Fossil on IIS

Anybody get Fossil working as a "CGI script" on Microsoft Server 2003 / IIS?

I'm trying to access multiple repositories with one script as described at:
http://www.fossil-scm.org/index.html/doc/trunk/www/server.wiki

Learned more than I ever wanted to know about IIS/CGI/Scripting.

[cid:image001.jpg@01CBEE12.FC5B3950]

TONY PEROVIC

tpero...@compumation.com
www.compumation.com

205 W. Grand Ave., Ste. 121
Bensenville, IL  60106
630-860-1921  Phone
630-860-1928  Fax



___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users



--
D. Richard Hipp
d...@sqlite.org
<>___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil on IIS

[Richard Hipp]

On Tue, Mar 29, 2011 at 2:14 PM, Tony Perovic wrote:

>  From RFC3875 Section 4.1,5:
>
>
>
> *The PATH_INFO variable specifies a path to be interpreted by the CGI*
>
> *script.  It identifies the resource or sub-resource to be returned by*
>
> *the CGI script, and is derived from the portion of the URI path*
>
> *hierarchy following the part that identifies the script itself**.*
>
>
>
> So, basically, my Perl script is taking a non-compliant IIS/CGI PATH_INFO
> and making it compliant.
>
>
Are their any other distinguishing environment variables that IIS outputs?
Perhaps we can add special code to Fossil to work around the IIS bug.

Or, perhaps we can add a special parameter to the "cgi" file that starts up
Fossil.  In addition to the "repository:" line, add a new line something
like:

 iis-bug-workaround=yes

The issue is that the PATH_INFO environment variable is not removing the
SCRIPT_NAME prefix?




>
> --
>
> **
>





> *From:* fossil-users-boun...@lists.fossil-scm.org [mailto:
> fossil-users-boun...@lists.fossil-scm.org] *On Behalf Of *Richard Hipp
> *Sent:* Tuesday, March 29, 2011 12:38 PM
>
> *To:* fossil-users@lists.fossil-scm.org
> *Subject:* Re: [fossil-users] Fossil on IIS
>
>
>
>
>
> On Tue, Mar 29, 2011 at 12:40 PM, Tony Perovic 
> wrote:
>
> This is driving me nuts……
>
>
>
> I created a CGI file for my repository on the server:
>
>
>
>
>
> It seems that Fossil uses the PATH_INFO to construct its reply in CGI mode.
> I achieved the correct results by writing a Perl script that strips the
> SCRIPT_NAME portion from the PATH_INFO environment variable before invoking
> Fossil:
>
>
>
> $path = $ENV{"PATH_INFO"};
>
> $script = $ENV{"SCRIPT_NAME"};
>
>
>
> if ($path =~ m/^$script/) { # PATH_INFO starts with SCRIPT_NAME?
>
> $ENV{"PATH_INFO"} = substr($path, length($script));
>
> }
>
>
>
> All Fossil / CGI requests must be processed through this Perl script. Thus,
> I concluded, Fossil/CGI cannot possibly work on Windows/IIS without
> scripting.
>
>
> Fossil assumes that PATH_INFO and SCRIPT_NAME are set up as described in
> RFC3875.  If what you say is correct, ISS appears not to follow RFC3875 and
> hence does not really support CGI, but rather something that is merely
> CGI-like.
>
>
>
>
>
> Q: Is this correct? Am I missing something?
>
>
>
> In fact, given the above analysis, it shouldn’t work in Linux either, yet,
> (I assume) it does.
>
>
> The main Fossil website (http://www.fossil-scm.org/) is just an instance
> of Fossil running on a Linux box as CGI.   See
> http://www.fossil-scm.org/fossil/doc/trunk/www/selfhost.wiki for
> additional information, including the scripts used to enable CGI on the
> various Fossil mirrors.
>
>
>
>
> Q: Can somebody please explain what is or isn’t happening in Linux that is
> or isn’t happening in Windows/IIS?
>
>
> Reminds me of a haiku I read years ago:
>
>
> Yesterday it worked.
> Today it is not working.
> Windows is like that.
>
>
>
>
> Tony Perovic
>
> Compumation, Inc.
>   --
>
> *From:* fossil-users-boun...@lists.fossil-scm.org [mailto:
> fossil-users-boun...@lists.fossil-scm.org] *On Behalf Of *Tony Perovic
> *Sent:* Tuesday, March 01, 2011 3:58 PM
>
>
> *To:* 'fossil-users@lists.fossil-scm.org'
>
> *Subject:* [fossil-users] Fossil on IIS
>
>
>
> Anybody get Fossil working as a “CGI script” on Microsoft Server 2003 /
> IIS?
>
>
>
> I’m trying to access multiple repositories with one script as described at:
>
> http://www.fossil-scm.org/index.html/doc/trunk/www/server.wiki
>
>
>
> Learned more than I ever wanted to know about IIS/CGI/Scripting.
>
>
>
>  *TONY PEROVIC*
>
>
>
> tpero...@compumation.com
>
> www.compumation.com
>
> 205 W. Grand Ave., Ste. 121
>
> Bensenville, IL  60106
>
> 630-860-1921  Phone
>
> 630-860-1928  Fax
>
>
>
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>
>
>
> --
> D. Richard Hipp
> d...@sqlite.org
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>


-- 
D. Richard Hipp
d...@sqlite.org
<>___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Summary of i18n status, for inclusion into Fossil introduction wiki

[Lluís Batlle i Rossell]

On Wed, Mar 30, 2011 at 01:32:17AM +0900, Clifford Caoile wrote:
> Hello fossil-users:
> 
> I was intrigued with Fossil after reading the enthusiastic LWN article
> [1]. Unfortunately I do not see any summary about Fossil and
> Internationalization (i18n). Let me contribute a summary which can be
> used on the Fossil wiki.

I agree with your summary. I also understand the current status that way.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil social networking

[Ron Wilson]

On Tue, Mar 29, 2011 at 10:55 AM, Bill Burdick  wrote:
> Functionality-wise, call-out hooks are OK for some things but a good,
> embedded scripting language is a simple way to do tightly integrated,
> cross-platform Fossil extensions, like Mercurial's plugins.
>...
> Also, Fossil is already a file system -- an embedded scripting language
> could run scripts stored as Fossil artifacts directly, so you wouldn't have
> to use the host file system to manage your scripts (and then maybe use yet
> another repository to version-control your hooks).  Lua and TCL are both
> good scripting languages; these days, Lua looks to be about 1/5 the size of
> TCL.

I see your point about an embedded scripting language. Another option
might be use load-on-demand shared libraries as plug-ins for Fossil.
In either case, the ability to spawn extenal programs would still be a
good idea.

As for choice scripting language, while Lua would be easier for me
than TCL, TCL might make more sense. Or at least extending the
functionality of TH1.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil on IIS

[Tony Perovic]

IIS/CGI sets the following environmental variable:
SERVER_SOFTWARE=Microsoft-IIS/6.0
So you could look for that.

IIS has another bug that prevents Set-Cookie and Redirection within the same 
HTTP response. IIS tries to be efficient by executing the redirection without 
involving the browser but fails to pass along the cookie so the Login/Logout 
pages don't work. I had to script around that too. Now that I've got all that 
worked out I'm battling the Active Directory security model. Painful.

Are you sure you want to start modifying Fossil to compensate for IIS 
idiosyncrasies (bugs)? Judging by the lack of responses I've gotten, I don't 
think there are too many Fossil on IIS/CGI users out there. A Wiki page with 
detailed instructions might suffice.

Regards,
Tony Perovic
Compumation, Inc.

From: fossil-users-boun...@lists.fossil-scm.org 
[mailto:fossil-users-boun...@lists.fossil-scm.org] On Behalf Of Richard Hipp
Sent: Tuesday, March 29, 2011 1:21 PM
To: fossil-users@lists.fossil-scm.org
Subject: Re: [fossil-users] Fossil on IIS


On Tue, Mar 29, 2011 at 2:14 PM, Tony Perovic 
mailto:tpero...@compumation.com>> wrote:
>From RFC3875 Section 4.1,5:


The PATH_INFO variable specifies a path to be interpreted by the CGI

script.  It identifies the resource or sub-resource to be returned by

the CGI script, and is derived from the portion of the URI path

hierarchy following the part that identifies the script itself.


So, basically, my Perl script is taking a non-compliant IIS/CGI PATH_INFO and 
making it compliant.

Are their any other distinguishing environment variables that IIS outputs?  
Perhaps we can add special code to Fossil to work around the IIS bug.

Or, perhaps we can add a special parameter to the "cgi" file that starts up 
Fossil.  In addition to the "repository:" line, add a new line something like:

 iis-bug-workaround=yes

The issue is that the PATH_INFO environment variable is not removing the 
SCRIPT_NAME prefix?









From: 
fossil-users-boun...@lists.fossil-scm.org
 
[mailto:fossil-users-boun...@lists.fossil-scm.org]
 On Behalf Of Richard Hipp
Sent: Tuesday, March 29, 2011 12:38 PM

To: fossil-users@lists.fossil-scm.org
Subject: Re: [fossil-users] Fossil on IIS


On Tue, Mar 29, 2011 at 12:40 PM, Tony Perovic 
mailto:tpero...@compumation.com>> wrote:
This is driving me nuts..

I created a CGI file for my repository on the server:


It seems that Fossil uses the PATH_INFO to construct its reply in CGI mode. I 
achieved the correct results by writing a Perl script that strips the 
SCRIPT_NAME portion from the PATH_INFO environment variable before invoking 
Fossil:

$path = $ENV{"PATH_INFO"};
$script = $ENV{"SCRIPT_NAME"};

if ($path =~ m/^$script/) { # PATH_INFO starts with SCRIPT_NAME?
$ENV{"PATH_INFO"} = substr($path, length($script));
}

All Fossil / CGI requests must be processed through this Perl script. Thus, I 
concluded, Fossil/CGI cannot possibly work on Windows/IIS without scripting.

Fossil assumes that PATH_INFO and SCRIPT_NAME are set up as described in 
RFC3875.  If what you say is correct, ISS appears not to follow RFC3875 and 
hence does not really support CGI, but rather something that is merely CGI-like.



Q: Is this correct? Am I missing something?

In fact, given the above analysis, it shouldn't work in Linux either, yet, (I 
assume) it does.

The main Fossil website (http://www.fossil-scm.org/) is just an instance of 
Fossil running on a Linux box as CGI.   See 
http://www.fossil-scm.org/fossil/doc/trunk/www/selfhost.wiki for additional 
information, including the scripts used to enable CGI on the various Fossil 
mirrors.


Q: Can somebody please explain what is or isn't happening in Linux that is or 
isn't happening in Windows/IIS?

Reminds me of a haiku I read years ago:

Yesterday it worked.
Today it is not working.
Windows is like that.


Tony Perovic
Compumation, Inc.

From: 
fossil-users-boun...@lists.fossil-scm.org
 
[mailto:fossil-users-boun...@lists.fossil-scm.org]
 On Behalf Of Tony Perovic
Sent: Tuesday, March 01, 2011 3:58 PM

To: 
'fossil-users@lists.fossil-scm.org'
Subject: [fossil-users] Fossil on IIS

Anybody get Fossil working as a "CGI script" on Microsoft Server 2003 / IIS?

I'm trying to access multiple repositories with one script as described at:
http://www.fossil-scm.org/index.html/doc/trunk/www/server.wiki

Learned more than I ever wanted to know about IIS/CGI/Scripting.

[cid:image001.jpg@01CBEE27.8ECC9AE0]

TONY PEROVIC

tpero...@compumation.com
www.compumation.com

205 W. Grand Ave., Ste. 121
Be

Re: [fossil-users] Client certificates and ticket 727af73f46

[Ron Wilson]

On Tue, Mar 29, 2011 at 11:02 AM, Jan Danielsson
 wrote:
>   The reason I used environment variables was that I couldn't figure
> out a good interface for managing certificates/keys.

One option, which could also solve the password protected cert issue,
would be to do as some versions of SSH do: A seperate cert management
agent. The agent, when starting, would allow the user to specify which
certs to make available, prompting for passwords as needed, then would
background itself and use inter-process communications to receive and
respond to requests from client processes. (Naturally, you would want
the agent to terminate when the user logs out.)

>   Finally, a known limitation is that it doesn't support password
> protected client keys. This is on my ToDo-list.

See above.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Sub-repositories?

[Ron Wilson]

On Tue, Mar 29, 2011 at 8:25 AM, Richard Hipp  wrote:
> We only allow the client "Reader" capabilities when accessing the subrepos.
> But for the main repo that contains the project wiki and other resources,
> the client has full "Setup" capability so that they can do whatever they
> want on their private repo without accidentally making undesirable changes
> to the subrepos.

Does that mean that users authorized to commit changes to the subrepos
must login directly to the respective subrepo? Does that also require
a seperate user ID from the single-sign-on ID?
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil on IIS

[Ron Wilson]

On Tue, Mar 29, 2011 at 4:39 PM, Tony Perovic wrote:

>  IIS has another bug that prevents Set-Cookie and Redirection within the
> same HTTP response. IIS tries to be efficient by executing the redirection
> without involving the browser but fails to pass along the cookie so the
> Login/Logout pages don’t work. I had to script around that too.
>

Seems to me that a meta reload HTML tag could be used, assuming IIS doesn't
mess with that, too. I have seen many websites that display a login-succeded
page that automatically loads the target page after a very short delay. I
assume this is done via meta reload.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil on IIS

[Tony Perovic]

I'm not familiar with the HTML meta reload tag...I had to google it.

Clicking the Login button, Fossil outputs this:

Status: 302 Moved Temporarily
Set-Cookie: fossil_login_3213c06d=anon%2F2455644... Path: 
/Projects/Test/Test.fossil; expires=Wed, 23 Mar 2011 23:51:39 GMT; Version=1
Location: /Projects/Test/Test.fossil/index
Cache-control: no-cache, no-store
Content-Type: text/html; charset=utf-8
Content-Length: 58


Redirect to /Fossil/Fossil.pl/index


My understanding is that the Location directive specifies the redirection. The 
... is only for Netscape compatibility.

IIS redirects to /Projects/Test/Test.fossil/index but forgets the cookie. Login 
fails.

So, are you suggesting I change that to:

Status: 302 Moved Temporarily
Set-Cookie: fossil_login_3213c06d=anon%2F2455644... Path: 
/Projects/Test/Test.fossil; expires=Wed, 23 Mar 2011 23:51:39 GMT; Version=1
Location: /Projects/Test/Test.fossil/index
Cache-control: no-cache, no-store
Content-Type: text/html; charset=utf-8
Content-Length: 109







Then see if the browser gets the cookie and redirects?

Tony Perovic
Compumation, Inc.

From: fossil-users-boun...@lists.fossil-scm.org 
[mailto:fossil-users-boun...@lists.fossil-scm.org] On Behalf Of Ron Wilson
Sent: Tuesday, March 29, 2011 4:11 PM
To: fossil-users@lists.fossil-scm.org
Subject: Re: [fossil-users] Fossil on IIS

On Tue, Mar 29, 2011 at 4:39 PM, Tony Perovic 
mailto:tpero...@compumation.com>> wrote:
IIS has another bug that prevents Set-Cookie and Redirection within the same 
HTTP response. IIS tries to be efficient by executing the redirection without 
involving the browser but fails to pass along the cookie so the Login/Logout 
pages don't work. I had to script around that too.

Seems to me that a meta reload HTML tag could be used, assuming IIS doesn't 
mess with that, too. I have seen many websites that display a login-succeded 
page that automatically loads the target page after a very short delay. I 
assume this is done via meta reload.

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil on IIS

[Tony Perovic]

Works with Chrome, but Microsoft Internet Explorer didn't like it.
Now, if I could just get the users to switch

Tony Perovic
Compumation, Inc.

From: Tony Perovic
Sent: Tuesday, March 29, 2011 4:39 PM
To: 'fossil-users@lists.fossil-scm.org'
Subject: RE: [fossil-users] Fossil on IIS

I'm not familiar with the HTML meta reload tag...I had to google it.

Clicking the Login button, Fossil outputs this:

Status: 302 Moved Temporarily
Set-Cookie: fossil_login_3213c06d=anon%2F2455644... Path: 
/Projects/Test/Test.fossil; expires=Wed, 23 Mar 2011 23:51:39 GMT; Version=1
Location: /Projects/Test/Test.fossil/index
Cache-control: no-cache, no-store
Content-Type: text/html; charset=utf-8
Content-Length: 58


Redirect to /Fossil/Fossil.pl/index


My understanding is that the Location directive specifies the redirection. The 
... is only for Netscape compatibility.

IIS redirects to /Projects/Test/Test.fossil/index but forgets the cookie. Login 
fails.

So, are you suggesting I change that to:

Status: 302 Moved Temporarily
Set-Cookie: fossil_login_3213c06d=anon%2F2455644... Path: 
/Projects/Test/Test.fossil; expires=Wed, 23 Mar 2011 23:51:39 GMT; Version=1
Location: /Projects/Test/Test.fossil/index
Cache-control: no-cache, no-store
Content-Type: text/html; charset=utf-8
Content-Length: 109







Then see if the browser gets the cookie and redirects?

Tony Perovic
Compumation, Inc.

From: fossil-users-boun...@lists.fossil-scm.org 
[mailto:fossil-users-boun...@lists.fossil-scm.org] On Behalf Of Ron Wilson
Sent: Tuesday, March 29, 2011 4:11 PM
To: fossil-users@lists.fossil-scm.org
Subject: Re: [fossil-users] Fossil on IIS

On Tue, Mar 29, 2011 at 4:39 PM, Tony Perovic 
mailto:tpero...@compumation.com>> wrote:
IIS has another bug that prevents Set-Cookie and Redirection within the same 
HTTP response. IIS tries to be efficient by executing the redirection without 
involving the browser but fails to pass along the cookie so the Login/Logout 
pages don't work. I had to script around that too.

Seems to me that a meta reload HTML tag could be used, assuming IIS doesn't 
mess with that, too. I have seen many websites that display a login-succeded 
page that automatically loads the target page after a very short delay. I 
assume this is done via meta reload.

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil on IIS

[Ron Wilson]

On Tue, Mar 29, 2011 at 5:39 PM, Tony Perovic  wrote:
> Clicking the Login button, Fossil outputs this:
> Status: 302 Moved Temporarily
> Set-Cookie: fossil_login_3213c06d=anon%2F2455644... Path:
> /Projects/Test/Test.fossil; expires=Wed, 23 Mar 2011 23:51:39 GMT; Version=1
> Location: /Projects/Test/Test.fossil/index
>
>
> 
> Redirect to /Fossil/Fossil.pl/index
> 
>
>
> My understanding is that the Location directive specifies the redirection.

As I recall, yes.

> The … is only for Netscape compatibility.

All html documents are supposed to start with  and end with .

> So, are you suggesting I change that to:
> Status: 302 Moved Temporarily

I was thinking "Status: 200 Ok".

>
> 
> 
> 
> 
> 

Otherwise, correct.

> Works with Chrome, but Microsoft Internet Explorer didn’t like it.
> Now, if I could just get the users to switch….

Maybe using status 200 would work.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Client certificates and ticket 727af73f46

[Jan Danielsson]

On 03/29/11 22:51, Ron Wilson wrote:
> On Tue, Mar 29, 2011 at 11:02 AM, Jan Danielsson
>  wrote:
>>   The reason I used environment variables was that I couldn't figure
>> out a good interface for managing certificates/keys.
> 
> One option, which could also solve the password protected cert issue,
> would be to do as some versions of SSH do: A seperate cert management
> agent. The agent, when starting, would allow the user to specify which
> certs to make available, prompting for passwords as needed, then would
> background itself and use inter-process communications to receive and
> respond to requests from client processes. (Naturally, you would want
> the agent to terminate when the user logs out.)

   Hmm.. I'm intrigued, but not completely convinced. An ssh/gpg:esque
agent solves the issue of having to re-enter the password, which is
obviously good if one does many operations within a short time-span over
https, but I'm not sure it would be the proper tool to keep track of
which certificates to associate with a particular project. It could
obviously be used for it, but I think it'll lead to unnecessary
complexity in the fossil code.

   To translate the environment variables to something which is more
"fossilic", I'm currently thinking along the lines of adding a new
sub-command "cert":

   $ fossil cert add myfoo --key ~/.certs/my.key --cert ~/.certs/my.crt
--cafile ~/.certs/ca.crt

   Creates a "container" called "myfoo" which contains references to the
client key, certificate and cafile as specified above. At this point it
doesn't actually do anything apart from being stored in the global
configuration. (Imagine ~ being expaned in the examples below).

   $ fossil cert list
   myfoo key=~/.certs/my.key cert=~/.certs/my.crt cafile=~/.certs/ca.crt

   Self-explanatory. Aim for easily machine-parsable output.

   $ fossil clone --cert myfoo https://foo.org/pub/proj proj.fossil
   [---]

   Every sub-command which takes an https url will support the "cert"
operation, which points out a "container". When the cert-option is used,
an association between the url and the cert container will automatically
be added to the global configuration (or overwritten if one already
exist). Next time foo.org is referenced via https, the association will
be "invoked" and the myfoo "container" will be used.

   $ fossil cert disassociate https://repos.foo.org

   This will make sure that any ssl operations to http://repos.foo.org
will no longer be fed the contents of myfoo. (Essentially, this is to
cover the very odd case where a server first requires a client
certificate, and at a later date doesn't, but the user wants to keep the
"myfoo" container for other systems).

   $ fossil cert delete myfoo

   Will remove the "myfoo" container, and all associated url assocations.

   The major problem with the current environment variable solution is
that there's no easy and logical way to remove an association which has
previously been established, and removing caching would require the
variables to be passed every time (or adding them to the shell's
exported environment variables, but this could quickly become annoying
if one switches between different repositories from different sources in
the same shell (I know I do)). And adding a single sub-command
specifically for removing an association seems overkill.

   The above system would allow users to only specify a cafile/capath,
solving the problems described in ticket 727af73f46.

   Any obvious caveats I've missed? Would sticking it all in the global
config table be okay, or would a new dedicated table for certificate
management be preferable?

>>   Finally, a known limitation is that it doesn't support password
>> protected client keys. This is on my ToDo-list.
> See above.

   I'll start by adding a simple password callback (as supported by
OpenSSL), and see how annoying it is to re-enter the password all the
time. I suspect you're right though, so I'll start planning for an agent
of some sort.

   Thanks for the feedback.

-- 
Kind regards,
Jan Danielsson




signature.asc
Description: OpenPGP digital signature
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Client certificates and ticket 727af73f46

[Ron Wilson]

On Tue, Mar 29, 2011 at 7:41 PM, Jan Danielsson
 wrote:
> Hmm.. I'm intrigued, but not completely convinced. An ssh/gpg:esque
> agent solves the issue of having to re-enter the password, which is
> obviously good if one does many operations within a short time-span over
> https, but I'm not sure it would be the proper tool to keep track of
> which certificates to associate with a particular project. It could
> obviously be used for it, but I think it'll lead to unnecessary
> complexity in the fossil code.

I think your own proposal answers this question:

>   To translate the environment variables to something which is more
> "fossilic", I'm currently thinking along the lines of adding a new
> sub-command "cert":
>
>   $ fossil cert add myfoo --key ~/.certs/my.key --cert ~/.certs/my.crt
> --cafile ~/.certs/ca.crt

Replace the file paths with cert and key IDs.

Now that you have mentioned it, it occurs to me that you might be able
to use gpg's agent.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users