The first time I tried to launch an API spec on Google Cloud Endpoints, it errored out on missing 'operationId'. Fair enough -- I should have seen that in the tutorial. What I don't understand is if there are any rules or guidelines governing what we assign to operationId and how it affects the environment.
The 'operationId' is mandatory. Beyond that, it needs to be unique within your OpenAPI spec. It is used only to identify the specific operation. It does not have any special effect on your environment.
Related
Some tests rely on some external services (e.g. APIs). Sometimes, these external services will go down. This can cause tests to fail and (worse) continuous integration tools to fail.
Is there a way to instruct testthat tests and regular package examples re-run examples/tests more than once, ideally with the second attempt being 5 minutes after the first?
Ideally you would write your tests in a way that they don't call API or database.
Instead you will mock API end points according to the specification and also write test for cases where API returns unexpected results or errors.
Here is an example of package that allows you to do so:
https://github.com/nealrichardson/httptest
If you are worried that your vendor might change API, talk to them and extract details on their API change management.
Ask them this:
What is your change management process?
How do you avoid introducing break changes to existing endpoints that people are using?
(modified from this post)
If you have to check that API is still the same, draw the line between API validation and testing of your code.
You will need two separate processes:
Unit / Acceptance tests that are executed against the mocks of the API end points. Those run fast and are focused on the logic of your application.
pipeline for regular validation of the API. If your code is already live, you are likely to find out of any breaking changes in API anyway. So this is highly redundant. In exceptional cases this can be useful, but only with a very bad vendor.
I am attempting to apply an ACL ruleset to members of a specific usergroup on a Linux box running Squid that I administer.
I have created the ruleset without much difficulty, but I am having difficulty configuring an authentication scheme that will only apply those rules to a specific subset of users on the system, while leaving the remainder of traffic untouched.
It seems that the auth_param setting is what I am looking for, but I haven't had much luck parsing the documentation.
Ideally, I would like an auth_param setting that sends the username to a shell script, which would check for that user's existence in the relevant group, and then return some value to determine whether or not to apply the rules to them.
The documentation seems to suggest that such a mechanism would be possible, but I haven't been able to find any relevant examples.
What is the best way to restrict a service account to the vision-api?
There are not obvious pre-defined roles that seems appropriate (or if there are, they are not named in an obvious way)
Before suggesting use of API key instead of service-account.json, consider that the Google Client API (which may wrap the REST api??) only seems to support use of ADC via an environment variable that points to the service-account.json file.
export GOOGLE_APPLICATION_CREDENTIALS=PATH_TO_KEY_FILE
https://cloud.google.com/vision/docs/auth
It is currently not possible.
You should subscribe to this ticket: https://issuetracker.google.com/issues/66035125
I am trying to understand the definitions in this document.
http://www.opengroup.org/soa/source-book/ontologyv2/service.htm
Their definitions of service, service interface and service contract are either unclear or seem different from what I normally encounter.
Service:
“A service is a logical representation of a repeatable activity that
has a specified outcome. It is self-contained and is a ‘black box’ to
its consumers.”
Lets say I have a WCF project and it has two Operations
StoreFront
+GetPrice
+AddToCart
The definition says "a repeatable activity". So is the service StoreFront? Or do I have two services (GetPrice and AddToCart).
Service Contract:
Has an "effect" class. Is the effect "return price" and " added to cart" ?
From the same article:
“A capability offered by one entity or entities to others using
well-defined ‘terms and conditions’ and interfaces.” (Source: OMG
SoaML Specification - my italics)
This is in my opinion a preferable defnition than the one talking about "repeatable activities".
The key word in the definition is capability. Capability refers to Business Capability which is a carry-over from the BPM industry, but in an SOA context refers to a business domain with distinct boundaries.
So from this definition we can surmise that services should be exposed or should operate within a business capability/process boundary. This leads us towards the idea (from the principals or tenants of SOA) that services should be autonomous within well defined boundaries.
In your example, you are asking
So is the service StoreFront? Or do I have two services (GetPrice and
AddToCart)
The answer to that as always is "it depends". However, generally Pricing (GetPrice) would belong to a different business capability to Ordering (AddToCart). Additionally, the operations differ in some other important ways:
GetPrice is a read operation, while AddToCart is a write operation.
GetPrice is a synchronous operation, while AddToCart could very well be asynchronous
So from these we should probably assume that they are two different services from a business perspective.
This assumption has some radical repercussions. If they are two services, then according to SOA they should be autonomous. Meaning that we should be looking to minimize coupling between the services in every possible way, so that as much as possible they can be planned, developed, tested, built, deployed, hosted, supported, and managerd as separate concerns.
Another repercussion is that when you physically separate services to this extent, how can you show this stuff together to your users? They may be different capabilities but they still need to work together on the screen.
Additionally, from a back end perspective Ordering needs to know about Pricing data, otherwise how can order fulfillment happen? If you've separated the database into two, how can the Checkout service know how much stuff costs, what discounts to apply, etc?
I have posted about this stuff before, so please feel free to have a read. I would recommend reading the excellent article on Microservices by Lewis and Fowler also.
My question is pretty simple:
If you have two web-application components:
Server-side (secret-capable) code in PHP, Python, Perl ... whatever
The javascript output and interpreted by the browser
Given a single redirection to the authorisation endpoint (and back) is it possible to specify and transfer the information for:
An authorization code grant (for the server-side code)
An implicit grant with restricted rights for the Javascript
thereby transferring the two grants (one in the request-url proper and the other in the fragment) in one round-trip without violating the RFC?
One redirect-loop seems cleaner than one for each grant (even if the second doesn't block due to previous authorization)
Thanks in advance!
References
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-16#section-4.2
edit 1: code_and_token seems to be the type of thing I am after ... an auth code grant for the server to request the access code using its credentials ... and an implicit token for the javascript. As mov matake mentions, it was pulled from the RFC after v11, with no real note as to why. Facebook and Google seem to support this which makes me suspect it will return.
The token_and_code request type was removed from the specification because it needed significant work in terms of security analysis and rules, and no one offered to do it. It was originally proposed by a Twitter engineer who left the working group shortly after.
It will not be added to the specification, but it can easily be introduced by an extension. Google supported this flow on the list, but later said they will not implement it, and instead, will implement something else using HTML5 features.
OAuth 2.0 had "code_and_token" response type before (might be "token_and_code").
But it had been removed from the spec later.
So in current spec, if you need code for your server, the way will be
use "code" response type
get an access token on server side
and give it to the client side
You can't get scope-restricted token only for client side though..
Or you might set up an proxy on your server side for your client side code.
http://www.ietf.org/mail-archive/web/oauth/current/msg04969.html and http://www.ietf.org/mail-archive/web/oauth/current/msg03655.html
says that the "code_and_token" type was good, but the RFC didn't make it clear enough that the token in the fragment (for Javascript) should/could have less rights than the token obtained by the access code...
Thanks Nov Matake for pointing out the code_and_token type was part of the spec (at one point) as I missed it in the old specification versions (though it is widely implemented).
Looks like it will make a comeback though, as it is quite well supported by existing implementations at Google and Facebook and seems to be a core request to support both user-agent tokens and server-side access codes in one round trip.
The problem seems to be defining the semantics of "scope" in this context as well as defining a degree to which scope can differ in a single request. It makes sense that the user-agent token has limited rights, ie not the same rights as the client application.
We shall wait and see ... the downside of implementing off the back of an involving RFC.