The matrix-auth 3.1 plugin now requires an Authorization type when granting users or group access to a project. Warning from plugin, "... it is recommended that all ambiguous entries are replaced with ones that are either explicitly a user or group." Is there an option in the job-dsl plugin to explicitly set the authorization type? I am using the latest version of the job-dsl plugin and I don't see a way to update the groovy files so that we are not seeing that warning.
I have it working using the following:
properties {
authorizationMatrix {
permissions([
"GROUP:Job/Read:authenticated",
"GROUP:Job/Build:<your github org>*<your github group>",
"GROUP:Job/Cancel:<your github org>*<your github group>"
])
inheritanceStrategy {
nonInheriting()
}
}
Get rid of the use of the authorization block in favour of the above.
Related
In dialogflow i have tried to add my fulfillment code directly in the inline editor for one my Intent response, but its failing. In Diagnostic info its showing the message:
Webhook call failed. Error: UNKNOWN. WebhookStatus code: 2
I tried to execute the function from Cloud function console directly and its working.
Inline editor code:
[1] https://i.stack.imgur.com/3FxTu.png
Error description image added below
[2]: https://i.stack.imgur.com/mOWor.png
Besides re-creating the Agent from scratch and clear browser cache:
Ensure your intent name matches the name of the intent handler defined in the fulfilment code.
In this Public Issue Tracker (PIT) the permissions can be another cause of the issue, so, check that allUsers is correctly set in your GCP project for the Fulfillment cloud function.
If the issue persists, according to the PIT, a workaround is to disable the Webhook and re-deploy. Once the deploy is done, disable the Inline Editor and utilize the Webhook URL again.
You can click the Vote for the PIT and get email notifications icon (the star) to register your support for the feature or add your specific issue.
I'm running WSO2 5.7.0, using OIDC with the Implicit Flow. I have set the context root to wso2-is, so the authorize endpoint is located at http://MY_DOMAIN/wso2-is/oauth2/authorize. When I begin the flow with a GET call to the oauth2/authorizeendpoint, I am redirected to http://MY_DOMAIN/authenticationendpoint/login.do?client_id=MY_CLIENT_ID&commonAuthCallerPath=%2Foauth2%2Fauthorize....
The problem is that it drops the context root and so later in the Implicit Flow I am (incorrectly) redirected to http://MY_DOMAIN/oauth2/authorize, which fails because that URL lacks the context root of wso2-is. How/where in the code is the commonAuthCallerPath parameter set?
As per the official documentation, using a reverse proxy is the recommended way to add a custom context path to wso2 products.
If you are not going to use a reverse proxy, I would suggest the following steps to add a custom context path. But, note that I have tested basic authentication with oauth2/oidc only.
Set WebContextRoot in repository/conf/carbon.xml to /wso2-is to change the context path of the carbon management console
Set ProxyContextPath in repository/conf/carbon.xml to /wso2-is
Rename oauth2.war and authenticationendpoint.war in repository/deployment/server/webapps/ by adding a prefix wso2-is#
Update repository/conf/indeitiy/identity.xml all the relevent instances of the following pattern by adding the context path /wso2-is after the port
${carbon.protocol}://${carbon.host}:${carbon.management.port}/xxxxx
to
${carbon.protocol}://${carbon.host}:${carbon.management.port}/wso2-is/xxxxx
Update AuthenticationEndpointURL, AuthenticationEndpointRetryURL and AuthenticationEndpointMissingClaimsURL values in repository/conf/identity/application-authentication.xml by adding /wso2-is prefix
Restart the Identity Server
Do not forget that, this is not the recommended way in the documentation.
I am using the code found here to base my signing class on:
https://gist.github.com/yvanin/0bdf68c1139ad698519e
From this I have been able to build an Authorisation header, but when this is passed along with my POST request, it fails with the error
The format of value 'Redacted' is invalid.
When I compare my authorisation header composure to an example found on the internet, it looks pretty much spot on (although i don't use Content-Type header as the request has no payload). Can anyone assist with where I might be going wrong?
Internet example is the top one below, mine is underneath. I have changed the relevant access key and signature data to obfuscate real values (EDIT: and obviously I'm trying to reach the API Gateway service, not IAM, so that's why I have execute-api in the header, have also tried apigateway and neither have any effect...)
// AWS4-HMAC-SHA256 Credential=AKIDEXAMPLE/20150830/us-east-1/iam/aws4_request, SignedHeaders=content-type;host;x-amz-date, Signature=5d672d79c15b13162d9279b0855cfba6789a8edb4c82c400e06b5924a6f2b5d7
// AWS4-HMAC-SHA256 Credential=AAAAI7T5JMMLSKVKA6EQ/20180302/ap-southeast-2/execute-api/aws4_request, SignedHeaders=host;x-amz-date, Signature=856bc41f18582836b56a02d9563c8f4f621fce7338ae2ec3afabe254a1543667
EDIT: Solved! So, when I first used the Sig V4 code at the github link, there was an extension function ParseQueryString that wouldn't resolve. It was because I was missing a reference to System.Net.Http.Formatting. Attempts to locate this library and add it failed, so I wrote my own extension method to do what I believed that function was doing.
Clearly my version of ParseQueryString was not right, because I finally solved the issue of the missing reference by locating a very specific version of the assembly to add via NuGet (any other versions produce the following error:
Unable to find a version of 'Microsoft.AspNet.WebApi.Client' that is compatible with 'System.Net.Http.Formatting
The specific version I required was:
PM> Install-Package System.Net.Http.Formatting -Version 4.0.20505
Once that was installed, and the ParseQueryString extension method I wrote was replaced with the standard one, viola! I now have a response from my API Gateway using IAM authorisation. It's a beautiful day :)
I am working on a C#/.Net serverless application using the AWS Visual Studio Toolkit, and I am having a bit of trouble figuring out what I am missing as far as CORS configuration. I based my project off of the ASP.Net example included with the toolkit, which configured API Gateway to have a single API endpoint that works as a proxy into the ASP.Net Web API framework.
In testing this application in chrome (serving a local node project) I am getting No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:8080' is therefore not allowed access.
I know this means I have to configure CORS on the API Gateway endpoint, but I seem to be missing something. I use the actions dropdown to enable CORS as such...
But I get some errors and the problem persists.
I used a chrome extension to disable CORS (temporarily) and have confirmed that the API endpoint works normally without CORS.
So what am I missing here? The examples of setting CORS online don't usually have instructions of a catch-all endpoint like this is set up to use, and even breaking GET into its own method didn't seem to help.
As an additional question, if there is some CORS configuration I am missing, is there a good way to get it integrated into the serverless.template file or some other automated deploy step?
It has to do with your ANY proxy method. As stated here: http://docs.aws.amazon.com/apigateway/latest/developerguide/how-to-cors.html
Note
When applying the above instructions to the ANY method in a proxy integration, any applicable CORS headers will not be set. Instead, you rely on the integration back end to return the applicable CORS headers, such as Access-Control-Allow-Origin
So you will have to make your backend API return the appropriate CORS headers.
You need to have the header on your server as well as the api gateway.
See this sample: - The cors header is applied to the static bucket website
https://www.codeproject.com/Articles/1178781/Serverless-Architecture-using-Csharp-and-AWS-Amazo
For the APIs to work properly two things must be done:
1. The options method must be correctly setup - usually done using a mock method on the API gateway.
2. The HTTP method implementations in your code must return the CORS header correctly. There are quite a few articles about this if you search.
For me the problem was Point 1; using the API Gateway 'Enable CORS' button did not work for me when I was developing API-Gateway Lambda integration using .NET Core. I also didn't find a way to add creation of the options method in the serverless.template file.
Here's another way to do it; after publishing the lambdas from CLI or VisualStudio, fire a PUT request on the API endpoint and pass a swagger definition which contains the options method defs and ensure you set the query param mode=merge. You can use PostMan to do this.
or
You use a DotNet utility which does the same thing explained here:
http://sbytestream.pythonanywhere.com/blog/Enabling-APIGateway-CORS
The source code is available on GitHub too.
I'm using the oauth playground for the Directory Members Update tool https://developers.google.com/admin-sdk/directory/v1/reference/members/patch
Whenever I try to update an existing member in the group I'm encountering an error 500 message. Is this a temporary issue or am I missing something.
When generating the request I am providing the groupKey, memberKey, and role:MEMBER for the patch body. If I provide the exact same arguments for the Update function things work just fine.
Thank you.
James
Only the role should be in the body since its the only value that is changing.