[fossil-users] TinyMCE for editing wiki pages

[Chris Rydalch]

I tried following the Cookbook page, but haven't had luck getting it to
work. I assume it's because a lot has changed in the last 8 years, both
with Fossil and TinyMCE. I tried adapting the instructions, but they don't
seem to be applicable anymore.

Does anyone have a recent example repo using TinyMCE to edit wiki pages?

Thanks in advance!
___
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 JSON API: How to create a wiki page?

[Stephan Beal]

Sorry, that last one is wrong. Instead, change:

http://fossil-scm.org/index.html/artifact?ln=1385=cc8d06a2d208ad00

To:

while(0); tmp = 0

(with no trailing semicolon)


- stephan
Sent from a mobile device, possibly from bed. Please excuse brevity, typos,
and top-posting.

On Jun 7, 2017 05:21, "Stephan Beal"  wrote:

> Aaaand: add 1 line between these two:
>
> http://fossil-scm.org/index.html/artifact?ln=1380-1381;
> name=cc8d06a2d208ad00
>
> Add:
>
> tmp = 0; \
>
> To avoid a separate (potential) corner case bug.
>
>
> - stephan
> Sent from a mobile device, possibly from bed. Please excuse brevity,
> typos, and top-posting.
>
> On Jun 7, 2017 05:07, "Stephan Beal"  wrote:
>
>> The error is triggered here:
>>
>> http://fossil-scm.org/index.html/artifact?ln=1518-1525=
>> cc8d06a2d208ad00
>>
>> Because of:
>> ... Hmmm... i THINK (not certain) it's because
>> json_respone_command_path() is, via, json_create_response() returning null
>> because of missing data in g.json. It interprets that as an alloc error,
>> but it's really a corner case. It could be fixed by adjusting:
>>
>> http://fossil-scm.org/index.html/artifact?ln=1413-1415=
>> cc8d06a2d208ad00
>>
>> To simply wrap that SET() callin if(tmp).
>>
>> i think.
>>
>> Wow, amazing what one can accomplish with fossil on a tablet from bed.
>>
>>
>>
>>
>> - stephan
>> Sent from a mobile device, possibly from bed. Please excuse brevity,
>> typos, and top-posting.
>>
>>
>> On Jun 7, 2017 04:44, "Stephan Beal"  wrote:
>>
>> Here we go:
>> http://fossil-scm.org/index.html/info/2accaaeeadd34cb6
>>
>>
>>
>> - stephan
>> Sent from a mobile device, possibly from bed. Please excuse brevity,
>> typos, and top-posting.
>>
>> On Jun 7, 2017 04:41, "Stephan Beal"  wrote:
>>
>>> Afaik, all errors except allocation failures do return the error in json
>>> form (i had to jump through some hoops to get that working way back then,
>>> due to fossil's fail-fast-via-exit() approach to error handling). The
>>>  mis-triggered alloc report here is, as you say, likely a side effect of
>>> the null fields, and should be easy to fix.
>>>
>>> Note that you don't need http to feed data to the json layer. There is a
>>> cli option (i think it's -json-input, but i am in bed so can't verify that
>>> right now) which tells it to read the POST data from a file.
>>>
>>>
>>> - stephan
>>> Sent from a mobile device, possibly from bed. Please excuse brevity,
>>> typos, and top-posting.
>>>
>>> On Jun 7, 2017 04:05, "Warren Young"  wrote:
>>>
 On Jun 6, 2017, at 5:58 PM, Stephan Beal  wrote:
 >
 > If you leave quotes off of the property names, it's not json

 Yes, but that’s only one of the three problems here.  The other two are:

 1. It should diagnose the error correctly.  (The error has nothing to
 do with memory allocation.)

 2. It should return the error message via JSON to the client, not print
 it on the console.  The JSON API is most likely to be used in cases where
 the called Fossil instance is running in the background, with stdio
 detached.

 > Why that shows up as a response allocation error, i can't say off
 hand.

 From what debugging I did, it’s because the parsing failure caused most
 of the fields of g.json to be unset, which causes multiple levels of NULL
 to be returned, which the scream-and-die code misinterprets as given.
 ___
 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

Re: [fossil-users] Fossil JSON API: How to create a wiki page?

[Stephan Beal]

Aaaand: add 1 line between these two:

http://fossil-scm.org/index.html/artifact?ln=1380-1381=cc8d06a2d208ad00

Add:

tmp = 0; \

To avoid a separate (potential) corner case bug.


- stephan
Sent from a mobile device, possibly from bed. Please excuse brevity, typos,
and top-posting.

On Jun 7, 2017 05:07, "Stephan Beal"  wrote:

> The error is triggered here:
>
> http://fossil-scm.org/index.html/artifact?ln=1518-1525;
> name=cc8d06a2d208ad00
>
> Because of:
> ... Hmmm... i THINK (not certain) it's because json_respone_command_path()
> is, via, json_create_response() returning null because of missing data in
> g.json. It interprets that as an alloc error, but it's really a corner
> case. It could be fixed by adjusting:
>
> http://fossil-scm.org/index.html/artifact?ln=1413-1415;
> name=cc8d06a2d208ad00
>
> To simply wrap that SET() callin if(tmp).
>
> i think.
>
> Wow, amazing what one can accomplish with fossil on a tablet from bed.
>
>
>
>
> - stephan
> Sent from a mobile device, possibly from bed. Please excuse brevity,
> typos, and top-posting.
>
>
> On Jun 7, 2017 04:44, "Stephan Beal"  wrote:
>
> Here we go:
> http://fossil-scm.org/index.html/info/2accaaeeadd34cb6
>
>
>
> - stephan
> Sent from a mobile device, possibly from bed. Please excuse brevity,
> typos, and top-posting.
>
> On Jun 7, 2017 04:41, "Stephan Beal"  wrote:
>
>> Afaik, all errors except allocation failures do return the error in json
>> form (i had to jump through some hoops to get that working way back then,
>> due to fossil's fail-fast-via-exit() approach to error handling). The
>>  mis-triggered alloc report here is, as you say, likely a side effect of
>> the null fields, and should be easy to fix.
>>
>> Note that you don't need http to feed data to the json layer. There is a
>> cli option (i think it's -json-input, but i am in bed so can't verify that
>> right now) which tells it to read the POST data from a file.
>>
>>
>> - stephan
>> Sent from a mobile device, possibly from bed. Please excuse brevity,
>> typos, and top-posting.
>>
>> On Jun 7, 2017 04:05, "Warren Young"  wrote:
>>
>>> On Jun 6, 2017, at 5:58 PM, Stephan Beal  wrote:
>>> >
>>> > If you leave quotes off of the property names, it's not json
>>>
>>> Yes, but that’s only one of the three problems here.  The other two are:
>>>
>>> 1. It should diagnose the error correctly.  (The error has nothing to do
>>> with memory allocation.)
>>>
>>> 2. It should return the error message via JSON to the client, not print
>>> it on the console.  The JSON API is most likely to be used in cases where
>>> the called Fossil instance is running in the background, with stdio
>>> detached.
>>>
>>> > Why that shows up as a response allocation error, i can't say off hand.
>>>
>>> From what debugging I did, it’s because the parsing failure caused most
>>> of the fields of g.json to be unset, which causes multiple levels of NULL
>>> to be returned, which the scream-and-die code misinterprets as given.
>>> ___
>>> 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

Re: [fossil-users] Fossil JSON API: How to create a wiki page?

[Stephan Beal]

The error is triggered here:

http://fossil-scm.org/index.html/artifact?ln=1518-1525=cc8d06a2d208ad00

Because of:
... Hmmm... i THINK (not certain) it's because json_respone_command_path()
is, via, json_create_response() returning null because of missing data in
g.json. It interprets that as an alloc error, but it's really a corner
case. It could be fixed by adjusting:

http://fossil-scm.org/index.html/artifact?ln=1413-1415=cc8d06a2d208ad00

To simply wrap that SET() callin if(tmp).

i think.

Wow, amazing what one can accomplish with fossil on a tablet from bed.




- stephan
Sent from a mobile device, possibly from bed. Please excuse brevity, typos,
and top-posting.


On Jun 7, 2017 04:44, "Stephan Beal"  wrote:

Here we go:
http://fossil-scm.org/index.html/info/2accaaeeadd34cb6



- stephan
Sent from a mobile device, possibly from bed. Please excuse brevity, typos,
and top-posting.

On Jun 7, 2017 04:41, "Stephan Beal"  wrote:

> Afaik, all errors except allocation failures do return the error in json
> form (i had to jump through some hoops to get that working way back then,
> due to fossil's fail-fast-via-exit() approach to error handling). The
>  mis-triggered alloc report here is, as you say, likely a side effect of
> the null fields, and should be easy to fix.
>
> Note that you don't need http to feed data to the json layer. There is a
> cli option (i think it's -json-input, but i am in bed so can't verify that
> right now) which tells it to read the POST data from a file.
>
>
> - stephan
> Sent from a mobile device, possibly from bed. Please excuse brevity,
> typos, and top-posting.
>
> On Jun 7, 2017 04:05, "Warren Young"  wrote:
>
>> On Jun 6, 2017, at 5:58 PM, Stephan Beal  wrote:
>> >
>> > If you leave quotes off of the property names, it's not json
>>
>> Yes, but that’s only one of the three problems here.  The other two are:
>>
>> 1. It should diagnose the error correctly.  (The error has nothing to do
>> with memory allocation.)
>>
>> 2. It should return the error message via JSON to the client, not print
>> it on the console.  The JSON API is most likely to be used in cases where
>> the called Fossil instance is running in the background, with stdio
>> detached.
>>
>> > Why that shows up as a response allocation error, i can't say off hand.
>>
>> From what debugging I did, it’s because the parsing failure caused most
>> of the fields of g.json to be unset, which causes multiple levels of NULL
>> to be returned, which the scream-and-die code misinterprets as given.
>> ___
>> 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] Make two fossil repositories "friends" ?

[Roy Keene]

All,

	I have two Fossil repositories hosted on the same server and 
serving related projects so it would be helpful to me to make them 
"friends" somehow...


Probably as an extension of the login-group functionality (and depndant 
upon it) would be some way to make Fossil look into its friends 
repositories for artifacts that are referenced that are not part of the 
current repository -- it could then just link to the other web interface 
for the other repository (meaning, that part of becoming friends would be 
identifying what the fossil URL prefix is for that peer).


Or something similar.  Right now for example, I have tickets and commits 
that I would like to use the "bracket" notation to refer to tickets and 
commits in other repositories but they are unknown in this repository.


Is such functionality already present in some way that I've missed, or has 
anyone investigated it ?


Thanks,
Roy Keene
___
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 JSON API: How to create a wiki page?

[Stephan Beal]

Here we go:
http://fossil-scm.org/index.html/info/2accaaeeadd34cb6


- stephan
Sent from a mobile device, possibly from bed. Please excuse brevity, typos,
and top-posting.

On Jun 7, 2017 04:41, "Stephan Beal"  wrote:

> Afaik, all errors except allocation failures do return the error in json
> form (i had to jump through some hoops to get that working way back then,
> due to fossil's fail-fast-via-exit() approach to error handling). The
>  mis-triggered alloc report here is, as you say, likely a side effect of
> the null fields, and should be easy to fix.
>
> Note that you don't need http to feed data to the json layer. There is a
> cli option (i think it's -json-input, but i am in bed so can't verify that
> right now) which tells it to read the POST data from a file.
>
>
> - stephan
> Sent from a mobile device, possibly from bed. Please excuse brevity,
> typos, and top-posting.
>
> On Jun 7, 2017 04:05, "Warren Young"  wrote:
>
>> On Jun 6, 2017, at 5:58 PM, Stephan Beal  wrote:
>> >
>> > If you leave quotes off of the property names, it's not json
>>
>> Yes, but that’s only one of the three problems here.  The other two are:
>>
>> 1. It should diagnose the error correctly.  (The error has nothing to do
>> with memory allocation.)
>>
>> 2. It should return the error message via JSON to the client, not print
>> it on the console.  The JSON API is most likely to be used in cases where
>> the called Fossil instance is running in the background, with stdio
>> detached.
>>
>> > Why that shows up as a response allocation error, i can't say off hand.
>>
>> From what debugging I did, it’s because the parsing failure caused most
>> of the fields of g.json to be unset, which causes multiple levels of NULL
>> to be returned, which the scream-and-die code misinterprets as given.
>> ___
>> 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

Re: [fossil-users] Fossil JSON API: How to create a wiki page?

[Stephan Beal]

Afaik, all errors except allocation failures do return the error in json
form (i had to jump through some hoops to get that working way back then,
due to fossil's fail-fast-via-exit() approach to error handling). The
 mis-triggered alloc report here is, as you say, likely a side effect of
the null fields, and should be easy to fix.

Note that you don't need http to feed data to the json layer. There is a
cli option (i think it's -json-input, but i am in bed so can't verify that
right now) which tells it to read the POST data from a file.


- stephan
Sent from a mobile device, possibly from bed. Please excuse brevity, typos,
and top-posting.

On Jun 7, 2017 04:05, "Warren Young"  wrote:

> On Jun 6, 2017, at 5:58 PM, Stephan Beal  wrote:
> >
> > If you leave quotes off of the property names, it's not json
>
> Yes, but that’s only one of the three problems here.  The other two are:
>
> 1. It should diagnose the error correctly.  (The error has nothing to do
> with memory allocation.)
>
> 2. It should return the error message via JSON to the client, not print it
> on the console.  The JSON API is most likely to be used in cases where the
> called Fossil instance is running in the background, with stdio detached.
>
> > Why that shows up as a response allocation error, i can't say off hand.
>
> From what debugging I did, it’s because the parsing failure caused most of
> the fields of g.json to be unset, which causes multiple levels of NULL to
> be returned, which the scream-and-die code misinterprets as given.
> ___
> 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

Re: [fossil-users] Fossil JSON API: How to create a wiki page?

[Warren Young]

On Jun 6, 2017, at 5:58 PM, Stephan Beal  wrote:
> 
> If you leave quotes off of the property names, it's not json

Yes, but that’s only one of the three problems here.  The other two are:

1. It should diagnose the error correctly.  (The error has nothing to do with 
memory allocation.)

2. It should return the error message via JSON to the client, not print it on 
the console.  The JSON API is most likely to be used in cases where the called 
Fossil instance is running in the background, with stdio detached.

> Why that shows up as a response allocation error, i can't say off hand.

From what debugging I did, it’s because the parsing failure caused most of the 
fields of g.json to be unset, which causes multiple levels of NULL to be 
returned, which the scream-and-die code misinterprets as given.
___
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 JSON API: How to create a wiki page?

[Warren Young]

On Jun 6, 2017, at 5:51 PM, Offray Vladimir Luna Cárdenas  
wrote:
> 
> When I try something similar with:
> 
> curl -H "Content-Type: application/json" \ -d '{"authToken":
> "mytoken",\
>"payload": {"name": “foo", "content": "bar"}}'
> http://localhost:8081/json/wiki/create

You’re missing a backslash between the JSON string and the URL.

The backslashes are largely for formatting reasons, so that I could continue a 
long command onto multiple lines in the email.  I recommend that you just type 
this as a single command, not copy-paste it as shown in the email.

Also, my mailer curled one of the quotes around “foo”, which you’ve copied into 
your command, and that will break the JSON parser.  It needs to be an ASCII 
double quote.

(I try to catch it when this happens, but sometimes my mailer is smarter than I 
am.)

> but if I do:
> 
> curl http://localhost:8081/json/wiki/timeline
> 
> I get:
> 
> {"fossil":"81d7d3f43ebd4e77095cfbacee7ebc9ae043a014760cde56d437dbd8b6a37c92","timestamp":1496792951,"command":"wiki/timeline","procTimeUs":,"procTimeMs":3,"payload":{"limit":20,"timeline":[]}}%
> 
> 
> So, wiki is properly served via JSON API from the local host.

That’s a much simpler call.  It doesn’t require any permissions, and it’s a GET 
call, not a POST call.  That test proves little other than that you have a 
working JSON API in your local Fossil instance.
___
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 JSON API: How to create a wiki page?

[Stephan Beal]

If you leave quotes off of the property names, it's not json and the
request cannot be parsed at all. Why that shows up as a response allocation
error, i can't say off hand. It's a bug - the response should be that the
request is missing data/parameters.


- stephan
Sent from a mobile device, possibly from bed. Please excuse brevity, typos,
and top-posting.

On Jun 6, 2017 23:04, "Warren Young"  wrote:

On Jun 6, 2017, at 1:09 PM, Offray Vladimir Luna Cárdenas 
wrote:
>
> I don't know how the page name is supposed to be given in the URL.

The document you point to says it’s supposed to be sent in the payload, not
in the request URL:

$ curl -H "Content-Type: application/json"  \
   -d '{"authToken": "nunyabinness",\
"payload": {"name": “foo", "content": "bar"} }' \
   http://localhost:8080/json/wiki/create

Incidentally, I found a bug while working that incantation out: if you
leave off the quotes around the property names, you get

fossil: Fatal error: could not allocate response object

on the console that is running the Fossil server instance.  All errors that
occur down the /json path should give a JSON reply, not kill off the forked
child with a vague and highly nonhelpful error.
___
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

Re: [fossil-users] Fossil JSON API: How to create a wiki page?

[Offray Vladimir Luna Cárdenas]

Thanks Warren for your quick answer.

When I try something similar with:

curl -H "Content-Type: application/json" \ -d '{"authToken":
"mytoken",\
"payload": {"name": “foo", "content": "bar"}}'
http://localhost:8081/json/wiki/create

I get:

curl: (6) Could not resolve host:  -d
curl: (3) [globbing] nested brace in column 141
{"fossil":"81d7d3f43ebd4e77095cfbacee7ebc9ae043a014760cde56d437dbd8b6a37c92","timestamp":1496792818,"resultCode":"FOSSIL-3002","resultText":"'name'
parameter is
missing.","command":"wiki/create","procTimeUs":0,"procTimeMs":0}%

but if I do:

curl http://localhost:8081/json/wiki/timeline

I get:

{"fossil":"81d7d3f43ebd4e77095cfbacee7ebc9ae043a014760cde56d437dbd8b6a37c92","timestamp":1496792951,"command":"wiki/timeline","procTimeUs":,"procTimeMs":3,"payload":{"limit":20,"timeline":[]}}%


So, wiki is properly served via JSON API from the local host.

What I'm missing?

Cheers,

Offray

On 06/06/17 16:04, Warren Young wrote:
> On Jun 6, 2017, at 1:09 PM, Offray Vladimir Luna Cárdenas  
> wrote:
>> I don't know how the page name is supposed to be given in the URL.
> The document you point to says it’s supposed to be sent in the payload, not 
> in the request URL:
>
> $ curl -H "Content-Type: application/json"  \
>-d '{"authToken": "nunyabinness",\
> "payload": {"name": “foo", "content": "bar"} }' \
>http://localhost:8080/json/wiki/create
>
> Incidentally, I found a bug while working that incantation out: if you leave 
> off the quotes around the property names, you get 
>
> fossil: Fatal error: could not allocate response object
>
> on the console that is running the Fossil server instance.  All errors that 
> occur down the /json path should give a JSON reply, not kill off the forked 
> child with a vague and highly nonhelpful error.
> ___
> 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

Re: [fossil-users] Fossil JSON API: How to create a wiki page?

[Warren Young]

On Jun 6, 2017, at 1:09 PM, Offray Vladimir Luna Cárdenas  
wrote:
> 
> I don't know how the page name is supposed to be given in the URL.

The document you point to says it’s supposed to be sent in the payload, not in 
the request URL:

$ curl -H "Content-Type: application/json"  \
   -d '{"authToken": "nunyabinness",\
"payload": {"name": “foo", "content": "bar"} }' \
   http://localhost:8080/json/wiki/create

Incidentally, I found a bug while working that incantation out: if you leave 
off the quotes around the property names, you get 

fossil: Fatal error: could not allocate response object

on the console that is running the Fossil server instance.  All errors that 
occur down the /json path should give a JSON reply, not kill off the forked 
child with a vague and highly nonhelpful error.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Fossil JSON API: How to create a wiki page?

[Offray Vladimir Luna Cárdenas]

Hi,

I've been trying to create a wiki page, ufollowing the documentation of
the Fossil JSON API
.
When I put the URL |http://myrepo.top/json/wiki/create?name=test| I get
and answer similar to:

|{"fossil":"81d7d3f43ebd4e77095cfbacee7ebc9ae043a014760cde56d437dbd8b6a37c92","timestamp":1496771043,"resultCode":"FOSSIL-3002","resultText":"'name'
parameter is
missing.","command":"wiki/create","procTimeUs":4000,"procTimeMs":4} |

I don't know how the page name is supposed to be given in the URL. I was
imagining that was similar to the way you query wiki pages, but seems
that the API is expecting something different. Could someone show me the
proper way of adding the page name to the Fossil JSON API URL?

Thanks,

Offray

___
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 http" doubts

[Richard Hipp]

On 6/6/17, Johan Kuuse  wrote:
> Hi,
>
> Is there any way to access the Fossil built-in webpages using the "fossil
> http"?
> In the example below, I try to access the /setup page from localhost,
> but it seems I don't get authorized. Instead I get redirected to the
> /login page.

You have to log in as a user with "s" (superuser) permission in order
to access the /setup page.  If you try to access /setup without the
right permissions, you get redirected.

Log in first, then try again.

-- 
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

[fossil-users] "fossil http" doubts

[Johan Kuuse]

Hi,

Is there any way to access the Fossil built-in webpages using the "fossil http"?
In the example below, I try to access the /setup page from localhost,
but it seems I don't get authorized. Instead I get redirected to the
/login page.

Best Regards,
Johan


fossil setting | grep localauth
localauth(local)  0

printf "GET /setup HTTP/1.0\n\n" | fossil http --localauth
HTTP/1.0 302 Moved Temporarily
Date: Tue, 6 Jun 2017 16:00:02 GMT
Connection: close
X-UA-Compatible: IE=edge
Location: http://login?g=/setup
X-Frame-Options: SAMEORIGIN
Cache-control: no-cache
Content-Type: text/html; charset=utf-8
Content-Length: 68


Redirect to Location: http://login?g=/setup




fossil version
This is fossil version 2.3 [1fff403a68] 2017-06-02 02:23:56 UTC
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Help messages in add.c

[Johan Kuuse]

Hi,

The following commands, executed without any arguments, are mute:

f add
f rm
f delete
f forget

IMHO, they should show a help message instead.

Best Regards,
Johan

fossil diff --unified
Index: src/add.c
==
--- src/add.c
+++ src/add.c
@@ -290,10 +290,12 @@
   const char *zIgnoreFlag;   /* The --ignore option or ignore-glob setting */
   Glob *pIgnore, *pClean;/* Ignore everything matching the glob patterns */
   unsigned scanFlags = 0;/* Flags passed to vfile_scan() */
   int forceFlag;

+  if( g.argc<3 ) usage("FILE1 ?FILE2? ...");
+
   zCleanFlag = find_option("clean",0,1);
   zIgnoreFlag = find_option("ignore",0,1);
   forceFlag = find_option("force","f",0)!=0;
   if( find_option("dotfiles",0,0)!=0 ) scanFlags |= SCAN_ALL;

@@ -453,10 +455,12 @@
   int removeFiles;
   int dryRunFlag;
   int softFlag;
   int hardFlag;
   Stmt loop;
+
+  if( g.argc<3 ) usage("FILE1 ?FILE2? ...");

   dryRunFlag = find_option("dry-run","n",0)!=0;
   softFlag = find_option("soft",0,0)!=0;
   hardFlag = find_option("hard",0,0)!=0;
Index: src/add.c
==
--- src/add.c
+++ src/add.c
@@ -290,10 +290,12 @@
   const char *zIgnoreFlag;   /* The --ignore option or ignore-glob setting */
   Glob *pIgnore, *pClean;/* Ignore everything matching the glob patterns */
   unsigned scanFlags = 0;/* Flags passed to vfile_scan() */
   int forceFlag;
 
+  if( g.argc<3 ) usage("FILE1 ?FILE2? ...");
+
   zCleanFlag = find_option("clean",0,1);
   zIgnoreFlag = find_option("ignore",0,1);
   forceFlag = find_option("force","f",0)!=0;
   if( find_option("dotfiles",0,0)!=0 ) scanFlags |= SCAN_ALL;
 
@@ -453,10 +455,12 @@
   int removeFiles;
   int dryRunFlag;
   int softFlag;
   int hardFlag;
   Stmt loop;
+
+  if( g.argc<3 ) usage("FILE1 ?FILE2? ...");
 
   dryRunFlag = find_option("dry-run","n",0)!=0;
   softFlag = find_option("soft",0,0)!=0;
   hardFlag = find_option("hard",0,0)!=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] Webpage for multiple fossil repositories - configuration options?

[John Pateman]

Yes, this was my usercase. Specifically I would like to configure the page 
generated by the `—repolist` option in `fossil server`. Whilst the `—files 
GLOBPATTERN` is helpful in so far as generating an alternative html page, I 
really wanted to be able to use a config option in `fossil server` to generate 
an HTML page which included the repolist (as well as some external 
files/images).

As a server option it does not need to be versionable or distributable - i.e. I 
am happy for it to reference a configuration file of .html, images etc in a 
configuration directory that sits alongside all the fossil repos.


JP


> On 6 Jun 2017, at 06:07, Ross Berteig  wrote:
> 
> 
> 
> On 6/5/2017 8:37 PM, Andreas Kupries wrote:
>> 
>> 
>> I am not sure that this would help him.
>> My reading of his request is that he wants to customize the page
>> generated by fossil itself [1].
> 
> That was my read too. The $64K question then is where such customization 
> would be stored. Skins are per repository, and this is running outside of all 
> repositories. There is the global settings location, of course, but that is 
> per user and you might (sensibly) be running that server as a daemon-like 
> user with no actual login, and possibly even no real home directory.
> 
> I suppose more command line options to fossil server is the easiest answer. 
> Extending the very vanilla HTML emitted to optionally name a style sheet if 
> named in a -CSS option, and to provide class documented and id attributes as 
> appropriate, would get you most of the way. Of course, the file named as the 
> style sheet must be automatically treated as named in the --files GLOBLIST so 
> it can be fetched or none of this works.
> 
> I'd suggest allowing a file full of TH1 code as the scripting escape to 
> provide hooks to compute additional details per repository listed, but I'm 
> not sure how safe that would be. Perhaps offering an option that names a 
> collection of well-known fields to include named with single letters would be 
> sufficient for most cases. Something like --details Lnd to also include the 
> Logo image, the project name, and the description. There are a bunch of 
> things in the /stat page that would sound tempting to include, but unless the 
> stats items are cached somewhere, that could have a huge cost at the server 
> for page fetch in a folder with a lot of repositories. Logo, name and 
> description are all easy, and likely have a fair bit of value. Project ID is 
> easy, but likely only interesting to us internals geeks. Age, number of 
> commits, number of open leaves, comment of latest commit, names of open 
> branches, owners first pet's name, are probably harder.
> 
> If the --details option is used, the page could be a table and use the same 
> sorting trick available to the ticket reports, which appears to work on any 
> number of table columns without any coding changes.
> 
> 
>> 
>> 
> 
> I like the idea in general. It could completely eliminate the need for cron 
> jobs to generate an index file, without a huge amount of configuration work.
> 
> --
> Ross Berteig   r...@cheshireeng.com
> Cheshire Engineering Corp.   http://www.CheshireEng.com/
> +1 626 303 1602
> 
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users



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