Can i sent POST(not PUT or PATCH) command if the config statement is false? How?
module system {
namespace "system:uri";
prefix "sys";
leaf id {
config false;
type string;
}
}
It's possible to define the leaf as a read-only in netconf or YANG? (after POST)
Config false nodes are not configurable. The server implementation sets their values. You cannot directly change the value of your id leaf. You can however instruct the server to do this indirectly, if you define a custom operation with such semantics.
rpc change-id {
input {
leaf new-id {
description "Sets the value of system:id.";
type string;
}
}
}
Obviously, the leaf would need to be really special to warrant something like this. You would then invoke the operation via POST:
POST /restconf/operations/system:change-id HTTP/1.1
Host: example.com
Content-Type: application/yang-data+json
{"system:input":{"new-id": "foo"}}
You will of course need to define proper semantics of your operation yourself.
P.S.: seeing that you asked a somewhat similar question here, perhaps what you really need is access control.
Related
I have one yang model, which is use to change run time parameter of my application.how i can make some parameter read only because some parameter when get change it impact on my code.I want user cannot change that parameter on run time.
notification bind-lne-name-failed {
description
"Indicates an error in the association of an interface to an
LNE. Only generated after success is initially returned when
bind-lne-name is set.";
leaf name {
type leafref {
path "/if:interfaces/if:interface/if:name";
}
mandatory true;
description
"Contains the interface name associated with the
failure.";
}
leaf bind-lne-name {
type leafref {
path "/if:interfaces/if:interface/lne:bind-lne-name";
}
mandatory true;
description
"Contains the bind-lne-name associated with the
failure.";
}
leaf error-info {
type string;
description
"Optionally, indicates the source of the assignment
failure.";
}
}
You've provided a YANG notification, which defines the structure of messages being sent from a YANG-capable server (for example, a NETCONF server) to a YANG-capable client (a NETCONF client) that has subscribed to it.
So notifications doesn't describe configuration data, but something the server sends to the client on its own.
I assume you have another yang model that does contain the data you want, which might overlap with the notification data.
Generically, you make leafs non-configurable by using the config keyword, which can have true or false values.
Here's an example on how that would look like in the error-info leaf:
leaf error-info {
type string;
config false;
description
"Optionally, indicates the source of the assignment
failure.";
}
By default, every data nodes are config true, meaning that they are writable, so that can be ommitted. For defining read-only data, you use config false.
You can find documentation on this keyword on the YANG RFC at https://www.rfc-editor.org/rfc/rfc6020#section-7.19.1
I have to migrate a lot of URLs with params, which look like that:
/somepath/somearticle.html?p1=v1&p2=v2 --> /some-other-path-a
and also the same URL without params:
/somepath/somearticle.html --> /some-other-path-b
The tricky part is that the two destination URLs are totally different pages in the new system, whereas in the old system the params just indicated which tab to open by default.
I tried different rewrite rules, but came to the conclusion that parameters are not considered by nginx rewrites. I found a way using location directives, but having 2000+ location directives just feels wrong.
Does anybody know an elegant way how to get this done? It may be worth noting that beside those 2000+ redirects, I have another 200.000(!) redirects. They already work, because they're rather simple. So what I want to emphasize is that performance should be key!
You cannot match the query string (anything from the ? onwards) in location and rewrite expressions, as it is not part of the normalized URI. See this document for details.
The entire URI is available in the $request_uri parameter. Using $request_uri may be problematic if the parameters are not sent in a consistent order.
To process many URIs, use a map directive, for example:
map $request_uri $redirect {
default 0;
/somepath/somearticle.html?p1=v1&p2=v2 /some-other-path-a;
/somepath/somearticle.html /some-other-path-b;
}
server {
...
if ($redirect) {
return 301 $redirect;
}
...
}
You can also use regular expressions in the map, for example, if the URIs also contain optional unmatched parameters. See this document for more.
I have http requests such as the one below being sent to an nginx server:
GET /app/handler?id=1234¶m1=cbd¶m2=234
Now, I want to rewrite the request to a different handler depending on the id param in the request. eg. redirect to handler_even for even ids and handler_odd for odd ids. This is shown below:
GET /app/handler?id=1234¶m1=cbd¶m2=234 => /app/handler_even?id=1234¶m1=cbd¶m2=234
GET /app/handler?id=123¶m1=cbd¶m2=234 => /app/handler_odd?id=123¶m1=cbd¶m2=234
I can do the rewrite using proxy_pass, but I'm unsure how to redirect using the id parameter value. Any idea how I could go about this? Would using "if" be the best way to go about this?
Any pointers would be useful
Rather than use an if directive, you could use a map. To internally rewrite the URI use:
map $arg_id $handler {
default /app/handler_even;
~[13579]$ /app/handler_odd;
}
server {
...
location = /app/handler {
rewrite ^ $handler last;
}
...
}
The map should be located at the same level as your server directive (as shown above), i.e. within the http container.
See this document for details.
if you have a REST API that is hypermedia-driven (HATEOAS) you can easily change a client's behavior by including or omitting links in the response (_links). That enables a client to completely forget about testing permissions for the operations that are possible in the current state of a resource (the link to the operation is present or not).
Additionally you can leave out properties in the response if the current user doesn't have permission to see it.
That way authorization is done entirely on the server (and controls actions and properties that are eligible to execute/view).
But what if I want to a have a read-only property? It is no problem for the REST API to ignore the property if it is present in the request (_POST_ OR _PUT_). it just won't get saved. But how can a client distinguish between write and read-only properties to present the user appropriate controls (like a disabled input field in HTML)?
The goal is to never ever have the client request a user's permissions, but to have a completely resource driven client/frontend.
Any help is greatly appreciated :-)
If I misunderstood your question, I apologize upfront. With that being said...
But how can a client distinguish between write and read-only
properties to present the user appropriate controls (like a disabled
input field in HTML)
Well, there are multiple solutions to this. The simplest one I can personally think of is to make each property an object having a simple structure of something like:
...
someProperty: {
value: 'some value',
access: 'read-only'
},
someOtherProperty: {
value: 'some value',
access: 'write'
}
...
You can obviously get as creative as you want with how you represent the "access" level of the property (using enums, booleans, changing access to be isReadOnly or whatever).
After that, the person using the API now knows they are read-only or not. If they submit a "write" value for a "read-only" property as part of the POST payload, then they should expect nothing less than a 403 response.
Edit:
In case you can't alter the properties in this manner, there are a number of other ways you can still achieve this:
write documentation that explains what access each property has
create a route that the user can submit 1 or more properties to in order to receive a response that indicates the access level of each property (response: { propName: 'read-only', propName2: 'write', etc.)
Return a propertyAccess map as part of the response (mapping properties to access levels).
end of the day, you just need a way to map a property with an access level. however that's done depends on what your restrictions and requirements are for the api, what changes you can make, and what is acceptable to both your client(s) and the business requirements.
Say we have the following server resource:
api.example.com/event/1
Which returns some arbitrary resource, say:
{
id: 1,
details: {
type: 'webinar',
....
},
attendees: [
{
user_id: 1,
first_name: 'Bob'
...
},
...
]
}
It might be useful for a client to make a request to get just the event details of the event but not the list of attendees.
Is it better to provided two separate URLs for the resources and force two separate requests if a client wants both resources?
api.example.com/event/{event_id}
api.example.com/attendees/{event_id}
Or is it better to offer the same two endpoints, but optionally have the first one support a GET param to toggle the attendee listing on or off
api.example.com/event/{event_id}?listAttendees={true|false}
api.example.com/attendees/{event_id}
Where the listAttendees parameter will either have the representation return the attendee list or not.
Is it an common practice to allow GET params to change the representation returned from a specific URL?
I'd say the most correct way to do that in REST would be with different media-types, or media-type parameters, but since most people don't use custom media-types, I often use something I call the zoom protocol. The idea is that you have a zoom or expand parameter, with a numeric value, and it recursively includes the children entities, decreasing the parameter until it reaches zero.
So, a request like:
GET api.example.com/event/1
Returns the plain representation for the event resource, without embedding anything. A request like:
GET api.example.com/event/1?zoom=1
Would include the immediate children of event, in your case, the atendees. Following on that:
GET api.example.com/event/1?zoom=2
Would include the immediate children of event, the immediate children of atendees.
To answer your question, in REST the whole URI is an atomic identifier, so the parameters are part of the URI. That can be a problem if you're using something that won't interpret URIs in the same way, like old cache servers who won't cache URIs with a querystring.