Below is the piece of code from Java Script(K6) that returns me Cookie.
I am trying to do the same in JMeter Groovy language.
let sso = JSON.stringify(response.request.cookies[`mygateid_sso`]);
let authToken_regex = /{'authToken':'(\S+?)'}/;
authToken = sso.match(authToken_regex)[0];
I am not finding a way to read response.request.cookies
In JMeter you have neither JSON as it's not a part of Nashorn engine nor response.request.cookies
If you want to access your mygateid_sso cookie the easiest way is:
Add HTTP Cookie Manager to your Test Plan
Add the next line to user.properties file (lives in "bin" folder of your JMeter installation)
CookieManager.save.cookies=true
Restart JMeter to pick up the change
That's it, you should be able to access your cookie as ${COOKIE_mygateid_sso} where required
More information: HTTP Cookie Manager Advanced Usage - A Guide
Related
I have an SSO setup using OpenAM 13.5 protecting an application on IIS with an IIS Web Agent.
The application receives user/session attributes by mapping the appropriate properties in the Agent configuration - everything is working fine, however I'd like to take things a step further: I'd like to pass the application a few agent properties as HTTP headers - i.e.:
CUSTOM-LOGIN-URL = com.sun.identity.agents.config.login.url
CUSTOM-EDITPASSWORD-URL = (set by a custom agent property)
CUSTOM-EDITPROFILE-URL = (set by a custom agent property)
CUSTOM-LOGOUT-URL = com.sun.identity.agents.config.logout.url
CUSTOM-GOTO-PARAMETER-NAME = com.sun.identity.agents.config.redirect.param
This way I could avoid hardwiring the application to the specific SSO config details.
Do you have any idea on how I could achieve that, possibly without writing code?
That's not possible OOTB. It might be possible by implementing https://backstage.forgerock.com/docs/openam/13.5/apidocs/com/sun/identity/entitlement/ResourceAttribute.html
Please see https://backstage.forgerock.com/docs/openam/13.5/dev-guide/#sec-policy-spi
Rather than having to change the URL passed in diet.listen() method on every server that I deploy my application on, there should be a better way to maintain such parameters in the application.
What options do we have to be able to manage such parameters?
You can create a '.json' file there at the root of the application and then do a require for the same. For example:
var configuration = require('./config.json');
The example expects you to save a file named 'config.json' with all your configuration as a JSON. The configuration object will hold all your settings that you might want to make dynamic and read at runtime.
I'm trying to run a number of api calls using dredd and api blueprint to test a site. I would like to run the tests on circleCI, as there are Selenium tests running in the same place. Each transaction needs to be accompanied by two tokens, which are set as cookies in the headers. Ideally, these would be set in the dredd.yml file. When running on a local machine, if I replace ACCESS_TOKEN and REFRESH_TOKEN with the actual values, the test runs as expected.
circle.yml:
test:
override:
- dredd
dredd.yml headers
header: ['Cookie: access_token=ACCESS_TOKEN; refresh_token=REFRESH_TOKEN']
Where ACCESS_TOKEN and REFRESH_TOKEN get replaced by the actual values set in circleCI's environment variables. I have also tried:access_token=$[ACCESS_TOKEN], access_token=$["ACCESS_TOKEN"] and access_token=$ACCESS_TOKEN. None of these are being replaced in the headers for the first api call.
The header looks like: {"Content-Type":"application/json; charset=utf-8","User-Agent":"Dredd/1.4.0 (Darwin 14.5.0; x64)","Cookie":" access_token=$ACCESS_TOKEN; refresh_token=$REFRESH_TOKEN"}
I am new to yaml files, so I'm probably missing something basic, but I did search around for a while. The hooks file is written with node.js, so I don't think the ruby/rails help will be useful here. If I am missing anything in the question don't hesitate to let me know.
YAML is a data representation language, not a template language (or template processor, for that matter). While an individual program might support loading environment variables or additional parameters named in the configuration, the YAML parser (probably, unless it's a custom module) isn't what's injecting them. While skimming the dredd docs I don't see any references to environment variables or parameters, it may be worth creating an issue on the project and starting a discussion with the developers to see if this is supported.
I can think of a number of ways to solve your specific problem, but they all involve additional tools to render the YAML with your variables injected. Perhaps the easiest solution for your case is to set environment variables in the CircleCI web configuration (NOT version-controled circle.yml). Then, set up a pre-build step, where the YAML configuration is generated. To do this, wrap the YAML in a BASH script, with the YAML document contained inside of it as a here-doc.
#!/bin/bash
# ACCESS_TOKEN and REFRESH_TOKEN are injected by CircleCI
cat <<EOF > config.yml
---
header: ['Cookie: access_token=${ACCESS_TOKEN}; refresh_token=${REFRESH_TOKEN}']
EOF
Then run the rest of your job normally, perhaps deleting the configuration file or restoring it from version control before any artifacts are created to avoid the leakage of your credentials.
The better way to work with headers is by Hook files setting headers before each request. As you are using Node.js, try set Node environment variables:
var hooks = require('hooks');
hooks.beforeEach(function(transaction) {
transaction.request.headers.Cookie =
'access_token=' + ACCESS_TOKEN +
'; refresh_token=' + REFRESH_TOKEN;
}
I'm trying to update Jenkins' root URL via the Groovy API, so I can script the deployment of a Jenkins master without manual input (aside: why is a tool as popular with the build/devops/automation community as Jenkins so resistant to automation?)
Based on this documentation, I believe I should be able to update the URL using the following script in the Script Console.
import jenkins.model.JenkinsLocationConfiguration
jlc = new jenkins.model.JenkinsLocationConfiguration()
jlc.setUrl("http://jenkins.my-org.com:8080/")
println(jlc.getUrl())
Briefly, this instantiates a JenkinsLocationConfiguration object; calls the setter setUrl with the desired value, http://jenkins.my-org.com:8080/; and prints out the new URL to confirm that it has changed.
The println statement prints what I expect it to, but following this, the value visible through the web interface at "Manage Jenkins" -> "Configure System" -> "Jenkins URL" has not updated as I expected.
I'm concerned that the value hasn't been update properly by Jenkins, which might lead to problems when communicating with external APIs.
Is this a valid way to fix the Jenkins root URL? If not, what is? Otherwise, why isn't the change being reflected in the config page?
You are creating a new JenkinsLocationConfiguration object, and updating the new one, not the existing one being used
use
jlc = JenkinsLocationConfiguration.get()
// ...
jlc.save()
to get the one from the global jenkins configuration, update it and save the config descriptor back.
see : https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/jenkins/model/JenkinsLocationConfiguration.java
I am trying to port a Perl script, which successfully reads and consumes Shibboleth session attributes, into Node.js. The Perl code looks, for example, like this:
die "Must be protected behind shibboleth authentication" unless $ENV{'AUTH_TYPE'} eq 'shibboleth';
die "Requires eppn" unless $ENV{'eppn'} ne "";
my $user = $ENV{'eppn'};
my $shib_session_id = $ENV{'Shib-Session-ID'};
It appears as though the Shibboleth attributes are available to Perl as environment variables. As far as I can tell (I don't know Perl), there is nothing within the script that is fetching or altering these values.
So, I checked process.env, in my Node.js app, and none of these values exist. Nor do they, as far as I have searched, exist in the request object created by Express.js.
The Perl script is on an Apache server, but nothing in the httpd.conf looks like it's passing anything special to the Perl script. My Node.js app is reversed proxied on the same Apache server.
Is it possible to get the Shibboleth attributes in Node.js, or does it rely on some Perl/Apache/Shibboleth magic?
Thanks to #mpapec's comment, I solved this by passing the Apache environment variables upstream as request headers:
RequestHeader set X-Auth-Type %{AUTH_TYPE}e
RequestHeader set X-EPPN %{eppn}e
RequestHeader set X-Shib-Session-ID %{Shib-Session-ID}e
These now appear in req.headers in my Node.js app; although X-Auth-Type is mysteriously set to (null)... I can work around that, for the time being, but any ideas why this is the case?