I have some code to retrieve a list of files from a repository (using REST API v3) and it worked great for many cases, but now I've hit a problem where it didn't work. Looking into this, I found that one of the elements of the response had this:
{
"mode": "160000",
"path": "folderA/folderB/folderC",
"sha": "84419db012d987a1705eea28055b278c17411a93",
"type": "commit"
}
If I look at that path using the browser, the folder is shown as:
- so after some confusion and embarrassement, I looked at things and concluded this must be a submodule (indeed it is mentioned in /.gitmodules.
I wonder how to best deal with that when I want to retrieve everything: currently my plan is to use path-entry to find a matching [submodule "path"] and then retrieve the tree from the repo using ther url from .gitmodules and sha from the response that I quoted. There is a path in .gitmodules, too - I guess that's just redundant? (Would be grateful for any other comments and suggestions. Maybe there is an easier approach to get thinghs?)
Also, I did not find doc about this - so is submodule the only reason for having commit in the respone, or could there be other cases to consider?
Update: it worked as I described! But I'm really concerned I might be hit by other unexpected items in the reply, so the question is really about documentation regarding the items in a response to querying the tress-API.
Related
I have a route definition in function.json: entity/{paramName}
When I make a GET request: http://localhost:7071/api/entity/50043e-315
In context.bindingData.paramName I get surprising 5.0043e-311, while context.req.params.paramName contains 50043e-315.
I noticed that here both ways of reading can be used; and here the same is meant, though the links are dead by now, while the example here mentions only context.bindingData.
Question: What is more preferable? And what is the difference?
I believe the problem here is that the somewhere (if I were to make a guess, here) the param is being parsed as a double before being stored as binding data. But when fetching it from the request object, it is fetched as a string from the URL directly. Hence the difference.
I believe there are only a few cases where this might happen and this is one of them.
I'm currently using istio 1.4 and had enabled a Policy to check jwt.
I enabled an AuthorizationPolicy which have that rule:
rules
- to:
- operation:
methods: ["GET"]
paths: [
"/render/checkout"
]
when:
- key: request.auth.claims[roles]
values: ["USER"]
When I hit that path with my jwt, every thing works great. The problem is when I hit the same url with a query string parameter for example /render/checkout?sort=asc, I get a RBAC: access denied.
to bypass this, I ended up adding the path including the question mark and a wildcard:
paths: [
"/render/checkout", "/render/checkout?*"
]
but having a lot of paths and a lot of microservices, I feel that should not happen as it happens because it's very repetitive and error prone.
I know that there's already an issue on github about supporting regex in paths, but currently :
Can I avoid doubling each of my paths, one without query string parameters and the second with the query string parameters?
There is a github issue where someone asked same question few days ago which leads us to github issue you add.
Specially this part of github member answer #GODBS.
There is no other way to exclude paths for JWT then to use an Authorization Policy which does not allow regex.
Can I avoid doubling each of my paths, one without query string parameters and the second with the query string parameters?
So as far as I understand currently there is no other way to make it work. The workaround for now is to add another paths, like you did.
I assume they will add it in the future, the question here is how long will it take.
I am sure I am not the first to encounter this, but I was unable to find a solution while Googling.
I am trying to add a drop-down list to my document. At the top of my model I am adding these namespaces:
use \DocuSign\eSign\Model\List;
use \DocuSign\eSign\Model\ListItem;
When doing so I get this error because "List" is a reserved word in PHP.
A PHP Error was encountered
Severity: Parsing Error
Message: syntax error, unexpected List (T_LIST), expecting identifier (T_STRING)
Filename: models/Docusign_model.php
Line Number: 19
I tried changing the name of the class from List to Elist but then I got errors from ObjectSerializer that it could not find Elist:swaggerType.
What am I missing on how to add a list to my document?
Thom
#thom I think this is really a "PHP" parsing question as is answered here for you Parse error: syntax error, unexpected (T_STRING), expecting variable (T_VARIABLE)
So I think the $ missing is your real issue as discussed in the referenced article above and below from PHP Manual.
http://www.php.net/manual/en/language.oop5.basic.php
Recommend you look at GIT example from SDK using CustomFieldList at https://github.com/docusign/docusign-php-client/blob/ccc86ac37334f34728361d73b2f8c4592225b8d2/src/Model/CustomFieldsEnvelope.php
excerpt
protected static $swaggerTypes = [
'list_custom_fields' => '\DocuSign\eSign\Model\ListCustomField[]',
'text_custom_fields' => '\DocuSign\eSign\Model\TextCustomField[]'
];
http://www.php.net/manual/en/language.oop5.basic.php
Also, maybe the first place to validate if you even need a specific "use" is by reviewing this PHP sample code from a good friend Ergin https://gist.github.com/Ergin008/d4a8b9210fbea41414b0
As I see it with most of the DocuSign SDK's, you have the client and specific services you want to use per excerpt below:
// Download PHP client: https://github.com/docusign/DocuSign-PHP-Client
require_once './DocuSign-PHP-Client/src/DocuSign_Client.php';
require_once './DocuSign-PHP-Client/src/service/DocuSign_RequestSignatureService.php';
require_once './DocuSign-PHP-Client/src/service/DocuSign_ViewsService.php';
Regardless if I am right or wrong, let us know if this helped you go in the right direction :-)
I would like to store a value in the config file and look it up in the design document for comparing against update values. I'm sure I have seen this but, for the life of me, I can't seem to remember how to do this.
UPDATE
I realize (after the first answer) that there was more than one way to interpret my question. Hopefully this example clears it up a little. Given a configuration:
curl -X PUT http://localhost:5984/_config/shared/token -d '"0123456789"'
I then want to be able to look it up in my design document
{
"_id": "_design/loadsecrets",
"validate_doc_update": {
"test": function (newDoc,oldDoc) {
if (newDoc.supersecret != magicobject.config.shared.token){
throw({unauthorized:"You don't know the super secret"});
}
}
}
}
It's the abilitly to do something like the magicobject.config.shared.token that I am looking for.
UPDATE 2
Another potentially useful (contrived) scenario
curl -X PUT http://trustedemployee:5984/_config/eventlogger/detaillevel -d '"0"'
curl -X PUT http://employee:5984/_config/eventlogger/detaillevel -d '"2"'
curl -X PUT http://vicepresident:5984/_config/eventlogger/detaillevel -d '"10"'
Then on devices tracking employee behaviour:
{
"_id": "_design/logger",
"updates": {
"logger": function (doc,req) {
if (!doc) {
doc = {_id:req.id};
}
if(req.level < magicobject.config.eventlogger.detaillevel ){
doc.details = req.details;
}
return [doc, req.details];
}
}
}
Here's a follow-up to my last answer with more general info:
There is no general way to use configuration, because CouchDB is designed with scalability, stability and predictability in mind. It has been designed using many principles of functional programming and pure functions, avoiding side effects as much as possible. This is a Good Thing™.
However, each type of function has additional parameters that you can use, depending on the context the function is called with:
show, list, update and filter functions are executed for each request, so they get the request object. Here you have the req.secObj and req.userCtx to (ab)use for common configuration. Also, AFAIK the this keyword is set to the current design document, so you can use the design doc to get common configuration (at least up to CouchDB 1.6 it worked).
view functions (map, reduce) don't have additional parameters, because the results of a view are written to disk and reused in subsequent calls. map functions must be pure (so don't use e.g. Math.random()). For shared configuration across view functions within a single design doc you can use CommonJS require(), but only within the views.lib key.
validate doc update functions are not necessarily executed within a user-triggered http request (they are called before each write, which might not be triggered only via http). So they have the userCtx and secObj added as separate parameters in their function signature.
So to sum up, you can use the following places for configuration:
userCtx for user-specific config. Use a special role (e.g. with a prefix) for storing small config bits. For example superLogin does this.
secObj for database-wide config. Use a special member name for small bits (as you should normally use roles instead of explicit user names, secObj.members.names or secObj.admins.names is a good place).
the design doc itself for design-doc-wide config. Best use the this.views.lib.config for this, as you can also read this key from within views. But keep in mind that all views are invalidated as soon as you change this key. So if the view results will stay the same no matter what the config values are, it might be better to use a this.config key.
Hope this helps! I can also add examples if you wish.
I think I know what you're talking about, and if I'm right then what you are asking for is no longer possible. (at least in v1.6 and v2.0, I'm not sure when this feature was removed)
There was a lesser-known trick that allowed a view/show/list/validation/etc function to access the parent design document as this in your function. For example:
{
"_id": "_design/hello-world",
"config": {
"PI": 3.14
},
"views": {
"test": {
"map": "function (doc) { emit(this.config.PI); })"
}
}
}
This was a really crazy idea, and I imagine it was removed because it created a circular dependency between the design document and the code of the view that made the process of invalidating/rebuilding a view index a very tricky affair.
I remember using this trick at some point in the distant past, but the feature is definitely gone now. (and likely to never return)
For your special use-case (validating a document with a secret token), there might be a workaround, but I'm not sure if the token might leak in some place. It all depends what your security requirements are.
You could abuse the 4th parameter to validate_doc_update, the securityObject (see the CouchDB docs) to store the secret token as the first admin name:
{
"test": "function (newDoc, oldDoc, userCtx, secObj) {
var token = secObj.admins.names[0];
if (newDoc.supersecret != token) {
throw({unauthorized:"You don't know the super secret"});
}
}"
}
So if you set the db's security object to {admins: {names: ["s3cr3t-t0k3n"], roles: ["_admin"]}}, you have to pass 's3cr3t-t0k3n' as the doc's supersecret property.
This is obviously a dirty hack, but as far as I remember, the security object may only be read or modified by admins, you wouldn't immediately leak your token to the public. But consider adding a separate layer between the CouchDB and your caller if you need "real" security.
Following this guide I create a design document with one view in it:
"views":{
"user":{
"map":"function(doc){emit(doc.id,doc)}"
}
}
If I then make a curl request like so:
curl .../_view/user
I get a result set, that looks like this:
{"total_rows":5,"offset":0,"rows":[{... value:{"_id":"...","login":"admin"}},...]}
If, however, I want to filter results by login field (now following this guide), like so:
curl ... /_view/user?login="test_login"
or ... /_view/user?login=test_login
I still get the very same result-set. I wonder what I'm doing wrong.
EDIT
I change the view a little bit, so that login attribute is now a key:
"map":"function(doc){emit(doc.login,doc)}"
However, even in this case filtering stil does not work. Whether I do:
/_view/user?login="root"
or
/_view/user?login="blahblahblah"
Taking all this into account, I guess, my final question should be: Does anybody in the world use CouchDB, if it is not working at all? I played around with dozens of databases, and all of them work as I expect it. CouchDB is a major exception.