I'm using the Python getdns API.
I'm using the extensions:
extensions = {"dnssec_return_validation_chain" : getdns.EXTENSION_TRUE}
This means that I'm told if the responses are DNSSEC secured with the dnssec_status option in the reply dictionary. (The results.replies_tree is an array of reply dictionaries.)
A query can have no replies if there is no name (e.g. results.status==getdns.RESPSTATUS_NO_NAME).
In this case, how do I know if the RESPSTATUS_NO_NAME response is authenticated with DNSSEC?
When the status is getdns.RESPSTATUS_NO_NAME, the replies_tree will contain replies with an empty "answer" section and return code NXDOMAIN. I.e. result.replies_tree[0]['header']['rcode']==getdns.RCODE_NXDOMAIN
When using a dnssec extension, these replies will contain the proof of non-existance in the "authority" section (when secure) and will contain a dnssec_status just as with replies that do contain answers.
When the status was insecure and the dnssec_return_validation_chain extension was used, result.validation_chain will contain proof of the non-existance of a secure delegation in one of the ancestors of the queried domain.
Related
Setting up my first Slack slash command. I built it out originally using the deprecated verification token but, for posterity, have decided to use signed secrets authentication.
Reading through the signed secrets documentation, I've had no issue validating requests that come in from the initial slash command. However, interaction requests have a completely different body structure and the method for calculating a secret hash do not produce a valid result (because the request body is different).
Here is a snippet from the docs on validating signed secrets.
slack_signing_secret = 'MY_SLACK_SIGNING_SECRET' // Set this as an environment variable
>>> 8f742231b10e8888abcd99yyyzzz85a5
request_body = request.body()
>>> token=xyzz0WbapA4vBCDEFasx0q6G&team_id=T1DC2JH3J&team_domain=testteamnow&channel_id=G8PSS9T3V&channel_name=foobar&user_id=U2CERLKJA&user_name=roadrunner&command=%2Fwebhook-collect&text=&response_url=https%3A%2F%2Fhooks.slack.com%2Fcommands%2FT1DC2JH3J%2F397700885554%2F96rGlfmibIGlgcZRskXaIFfN&trigger_id=398738663015.47445629121.803a0bc887a14d10d2c447fce8b6703c
On invocation of the slash command this works as intended - the request body matches the structure in the example above. When the user interacts with the message, the response body uses the blocks api - which is completely different
If I'm not supposed to use the verification token and the request body from the interactive blocks api does not allow me to compute a valid hash, how am I supposed to validate interaction requests? I must be missing something while combing through the docs.
For example, should controller return updated entity after update?
To fit into your question we can set the "best practices" in the range of the verbs. What is the best option to return for each verb?
I'm going to use the book RESTful Web Services (Chapter 4) to answer your question.
This is textual iformation from the book, none of the following words are mine.
GET
The server sends back a representation in the response entity-body.
POST
Response of POST request usually has an HTTP status code of 201 ("Created"). Its Location header contains the URI of the newly created resource.
PUT
The entity-body contains the client's proposed new representation of the resource. What data this is, and what format it's in, depends on the service.
DELETE
The response entity-body may contain a status message or nothing at all
HEAD
Retrieve a metadata-only representation.
A client can use HEAD to check wheter a resource exists, or find out other information about the resource, without fetching its entire representation. HEAD gives you exactly what a GET request would give you, but without the entity-body
OPTIONS
Contains the HTTP Allow header, which lays out the subset of the uniform interface this resource supports.
I have MESSAGE-ID from email which I send.
How to filter email in IMAP "all mailboxes" to fined email which are response to my MESSAGE-ID .
Currently I know that in response I need to look for "Original-Envelope-Id".
But how to do this with Chilkat ?
Do I need to use $imap.Search(....)
https://www.chilkatsoft.com/refdoc/csImapRef.html#method70
?
With:
UID
Messages with unique identifiers corresponding to the specified
unique identifier set. Sequence set ranges are permitted.
?
btw.
I already check this example
https://www.example-code.com/powershell/imap_search.asp
But he is not related to search for email response.
Chilkat is passing the search criteria string to the IMAP server unmodified. Therefore, it's really just a matter of understanding the IMAP specification for search criteria as documented in RFC 3501 here: https://www.rfc-editor.org/rfc/rfc3501#section-6.4.4
If you look at the RFC, this is the way to specify a search for a particular header field:
HEADER <field-name> <string>
Messages that have a header with the specified field-name (as
defined in [RFC-2822]) and that contains the specified string
in the text of the header (what comes after the colon). If the
string to search is zero-length, this matches all messages that
have a header line with the specified field-name regardless of
the contents.
However.. my experience is that most IMAP server implementations don't implement all possible SEARCH criteria options.
I am defining a rest path for a many to many relationships.
I want to get a list of users which are guest of a company.
Is the path below sufficient?
/api/v1/users/companies/{companyId}/guests
Because I put it in UserController so it cant not be
/api/v1/companies/{companyId}/guests
Do you have any suggestion?
I primarily intended to write a comment, but it's the way too long so I've written an answer instead.
First of all, REST is an architectural style and not a cookbook for designing URIs. REST doesn't enforce any URI design (as long as it's compliant with the RFC 3986) and it's totally up to you to pick the URIs that better identify your resources.
Do you have any suggestion?
Answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. What you'll read from this point is my personal opinion.
If the guests and the companies resources can be managed independently, I would use the following mappings:
/companies
/guests
Then you can use a query parameter to filter the guests for a given company:
GET /guests?company={id} HTTP/1.1
Host: example.org
To create a guest resource for a given company, you could use:
POST /guests HTTP/1.1
Host: example.org
Content-Type: application/json
{
"name": "John Appleseed",
"companyId": 1
}
REST doesn't care what spellings you use for your resource identifiers, so long as they are consistent with the production rules defined in RFC 3986.
/api/v1/users/companies/{companyId}/guests
That's fine
/api/v1/companies/{companyId}/guests
That would also be fine.
/d4158568-c40f-4c51-93cd-25642f6f42e2
So would that.
/api/v1/companies/guests?companyId={companyId}
On the web, you are perhaps more likely to see an identifier like this one; forms are a useful way of enabling a client to provide data, and HTML has production rules for creating a URI from data in a form. Of course, HTTP also has mechanisms that allow you to redirect the clients attention from one URI to another, so you don't have to restrict identifiers to those appropriate for a specific client.
JSON API REST endpoint with permissions-restricted fields
I am working on a JSON API-compliant REST api. Some endpoints contain fields that should be restricted (read-only or not available) for certain users.
What is the best way to architect the api to allow that certain users have access to certain fields, while others do not? By "best", I mean:
Most compliant with REST standards, ideally JSON API standards
Most clarity in terms of preventing bugs and confusion on behalf of clients consuming the API
I am considering the following options, each with their set of concerns/ questions. I would be more than grateful for any other solutions!
Option 1: Return null on restricted fields for users without permissions
Different data values would be returned per-user. Is this strictly anti-REST?
Lack of distinction between null meaning "null value" and null meaning "You don't have access to this"
In REST/ JSON API architecture, is it okay for an endpoint to return different data per user, based on permissions? I have the impression that this would be contrary to the spirit of resource-based REST architecture, but I could not find anything specific to point to in any doc or standard (e.g. JSON API). Also applies to Option 2.
Is there any paradigm for adding some sort of "You don't have access" flag in the resource's metadata?
Option 2: Exclude restricted fields entirely for users without permissions
Different data values would be returned per-user. Is this strictly anti-REST?
Possibility of "undefined" errors in client, when trying to retrieve field value
Option 3: Move restricted field(s) onto another endpoint, available as an ?include='field_name' relation for those with permission
Example: /api/entity includes attribute field "cost" which is only available to Admin users. Admin users can request cost data via GET /api/entity?include=cost. For all users, "cost" is exposed as a relation in the resource object, with a "type" and "id".
This is the option I am leaning toward. The main con here is endpoint clutter. I have a lot of relations that would need to be made into separate endpoints, simply to support a permissions-quarantined data on an already-existing endpoint.
In the JSON API specs, I am having trouble determining if it's ok for an endpoint to exist as a relation only, e.g. can we have /api/entity/1/cost, but NOT have a top-level api endpoint, /api/cost. My assumption is that if a resource has a "type" (in this case, the relation type being 'cost'), it also has to live on a top-level endpoint.
In this scenario, the client could get a 401: Unauthorized error response if a non-admin user tries to GET /api/entity?include=cost or GET /api/cost/:id
Note: I have already built a separate permissions schema so that the client can determine which CRUD privileges the user has, per top-level endpoint, before making any requests. Permission sets are indexed by resource type.
Any help on the matter would be very much appreciated! And if anything needs to be clarified, feel free to ask.
I would definitely not use undefined or null to indicate fields that the user is not allowed to see. To me, that feels like a lie and represents that the data is really not there. They would have to really know your API in order to get a grasp of what is really going on.
I would recommend something more like your 3rd option, except I would make it a different endpoint altogether. So in your example, the endpoints would be:
/api/entity/1/cost
and for admins
/api/admin/entity/1/cost
or something like that.
This way your server code for the admin endpoint could just be focused on authenticating this admin user and getting them back all the fields that they have visibility on. If a non admin user tries to hit that route, reject them with an unauthorized status code.
I'm not saying that you should not implement the GET param to be able to specify fields as well. You can if you want to, but I don't think it just won't be necessary in this case.