On 1/28/2016 5:02 AM, Stephan Beal wrote:
.... Related: https://www.fossil-scm.org/index.html/info/9b8b051899ca59b4 Hmmm. The test code: # json cap # Bug? The CLI user has all rights, and no auth token affects that. write_file u2 [subst { {"command":"cap", "authToken":"[dict get $AuthAnon]" } }] fossil_json --json-input u2 i would have thought that that would do, but apparently it doesn't. i find the following comment (probably written by a much younger me) in json.c:json_auth_token(): /* Reminder: chicken/egg scenario regarding db access in CLI mode because login_cookie_name() needs the db. CLI mode does not use any authentication, so we don't need to support it here. */
I'm ok with declaring the CLI as effectively having 's'. I just wanted confirmation that it was expected before I baked it into a test case that way.
Perhaps oddly, I don't have a problem with the CLI being able to exercise the login subcommand or the anonymous login handshake. That makes it easier to test those features, as long as they do work as expected with fossil http. Next on today's agenda is to pass auth tokens through that interface and verify that the caps do reflect what was provided to the user.
I've kicked the can on fully testing authentication down the road a bit since I need to use HTTP POST and none of my cases do that yet. In the mean time, I'm checking the capabilities field returned by /json/login and verifying that it includes the expected caps.
I added a quick check for /json/whoami doing something vaguely sensible in the CLI. It does. And am moving on down the major features.
That might be the root of the problem.
Yup.
Unrelated: i see in the test script that it adds an empty file, and that got me curious... it seems we already have one: [odroid@host:~/fossil/fossil/test]$ f sqlite "select * from blob where uuid='da39a3ee5e6b4b0d3255bfef95601890afd80709'"; 525|1|0|da39a3ee5e6b4b0d3255bfef95601890afd80709| [odroid@host:~/fossil/fossil/test]$ f-query -e "select fsl_content(525)" fsl_content(525) Maybe that can save you an add/commit.
That empty file (and several more just like it) are in fossil's own repository. My plan is to avoid like the plague any need to run the JSON tests in a checkout of any repository not created by and under the full control of a test case.
I think that is a good style point to establish for all test cases, actually. Joe has narrowed the scope of tests running in the real repository down quite a bit, and my hope is that in the future it could be narrowed further.
The test framework as it stands today cannot be run from within any open checkout, but does require that it be able to find an open checkout of fossil itself for those remaining tests that assume they have fossil's own repo open.
-- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 _______________________________________________ fossil-dev mailing list fossil-dev@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
