Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents

Key Points

...

curl-flaviocopes.com-The curl guide to HTTP requests.pdf


Using cURL to authenticate with JWT Bearer tokens

Get the Bearer token using cURL and jq

TOKEN=$(curl -s -X POST -H 'Accept: application/json' -H 'Content-Type: application/json' --data '{"username":"{username}","password":"{password}","rememberMe":false}' https://{hostname}/api/authenticate | jq -r '.id_token')




Setting and Using Access Bearer Tokens ( JWT ) with Curl

pipe the output of a curl command to an environment variable and use it in another curl command?

I have a REST endpoint that I can get an access token from. To get the access token (JSON web token, JWT) and export that value as an environment variable, I do the following.

export ACCESS_TOKEN=$(curl -i -H 'Content-Type: application/json' -X POST -d @credentials.json http://localhost:8080/api/user/login)

I then echo this token back to the console with echo $ACCESS_TOKEN and get something like this.

 eyJhbGciOiJIUzUxMiJ9.eyJzdWIiOiI1MTBlMjRiYWZmZTY0NjMyOGRiNjg1N2ViMTdlZTE1NCIsImFkZHIiOiIwOjA6MDowOjA6MDowOjEiLCJzY2hlbWUiOiJodHRwIiwicG9ydCI6IjgwODAiLCJpYXQiOjE0NjgzNzg5NDV9.COGBYBrx3oQvA2kIiObBOYkEFIL2BODcrSivxWvhuLs-aLsrMGO2z2aCddpwS2yZUB88Q3GOIU8QklbnfRMprQ

Note that there is a space before the first character. I didn't think that was a problem because if I exported the value directly from the console and then echoed it back out, the space is still there.

export ACCESS_TOKEN=eyJhbGciOiJIUzUxMiJ9.eyJzdWIiOiI1MTBlMjRiYWZmZTY0NjMyOGRiNjg1N2ViMTdlZTE1NCIsImFkZHIiOiIwOjA6MDowOjA6MDowOjEiLCJzY2hlbWUiOiJodHRwIiwicG9ydCI6IjgwODAiLCJpYXQiOjE0NjgzNzg5NDV9.COGBYBrx3oQvA2kIiObBOYkEFIL2BODcrSivxWvhuLs-aLsrMGO2z2aCddpwS2yZUB88Q3GOIU8QklbnfRMprQ

Now I need to use this token to test my REST endpoints, and tried something like the following.

curl -i \
 -H 'x-access-token: '$ACCESS_TOKEN'' \
 -X POST -d @mydata.json \
 http://localhost:8080/api/data

However, I get the following output.

curl: (7) Couldn't connect to server
curl: (3) Illegal characters found in URL


If I just directly do export ACCESS_TOKEN=.... in the shell followed by the exact same curl command, then everything works.

Also if I put the export in a sh file, followed by the curl command above then it also works.

#!/bin/bash
export ACCESS_TOKEN=eyJhbGciOiJIUzUxMiJ9.eyJzdWIiOiI1MTBlMjRiYWZmZTY0NjMyOGRiNjg1N2V



i>> The problem was with the use of -i as this option includes the headers in the output.

The strange thing is that unless you do echo "$ACCESS_TOKEN" you won't see the headers polluting the REST response coming back.

Simply remove -i and it should work.



Swagger - OpenAPI




Postman - API Test Tool

...

https://github.com/postmanlabs/postman-app-support/issues/2646

Problem

Sending a request to some pages, keep getting the error 'Javascript is disabled on your browser. Please enable Javascript and refresh this page'. The page works on the browser but on Postman it comes up with that error. Initially thought it was the page so tried another and still keep getting the error

Solution

  1. Postman Version: 4.9.3
  2. App (Chrome app or Mac app): Mac app
  3. OS details: 10.12.2
  4. Is the Interceptor on and enabled in the app: No
  5. Did you encounter this recently, or has this bug always been there: N/A
  6. Expected behaviour: N/A
  7. Console logs (http://blog.getpostman.com/2014/01/27/enabling-chrome-developer-tools-inside-postman/ for the Chrome App, View->Toggle Dev Tools for the Mac app): N/A
  8. Screenshots (if applicable) N/A

...

Robot Framework is actively supported, with many industry-leading companies using it in their software development.

Robot Framework is open and extensible and can be integrated with virtually any other tool to create powerful and flexible automation solutions. Being open source also means that Robot Framework is free to use without licensing costs.


Robot Framework has easy syntax, utilizing human-readable keywords. Its capabilities can be extended by libraries implemented with Python or Java. The framework has a rich ecosystem around it, consisting of libraries and tools that are developed as separate projects.

...

Libraries contain framework functions

Libraries provide the actual automation and testing capabilities to Robot Framework by providing keywords. Several standard libraries are bundled in with the framework, and galore of separately developed external libraries that can be installed based on your needs. Creating your own libraries is a breeze.


Standard


Builtin
Provides a set of often needed generic keywords. Always automatically available without imports.

...

Now make a directory called "features/". In that directory create a file called "example.feature" containing:

# -- FILE: features/example.feature
Feature: Showing off behave

  Scenario: Run a simple test
    Given we have behave installed
     When we implement 5 tests
     Then behave will test them for us!

Make a new directory called "features/steps/". In that directory create a file called "example_steps.py" containing:

# -- FILE: features/steps/example_steps.py
from behave import given, when, then, step

@given('we have behave installed')
def step_impl(context):
    pass

@when('we implement {number:d} tests')
def step_impl(context, number):  # -- NOTE: number is converted into integer
    assert number > 1 or number == 0
    context.tests_count = number

@then('behave will test them for us!')
def step_impl(context):
    assert context.failed is False
    assert context.tests_count >= 0

Run behave:

$ behave
Feature: Showing off behave # features/example.feature:2

  Scenario: Run a simple test          # features/example.feature:4
    Given we have behave installed     # features/steps/example_steps.py:4
    When we implement 5 tests          # features/steps/example_steps.py:8
    Then behave will test them for us! # features/steps/example_steps.py:13

1 feature passed, 0 failed, 0 skipped
1 scenario passed, 0 failed, 0 skipped
3 steps passed, 0 failed, 0 skipped, 0 undefined

...

trader_is_alerted_of_status.story.

Given a stock of symbol STK1 and a threshold of 10.0
When the stock is traded at 5.0
Then the alert status should be OFF

...

Configure Stories with data scenarios 

At the heart of the JBehave running of stories lies the Embedder, which provides an entry point to all of JBehave's functionality that is embeddable into other launchers, such as IDEs or CLIs. JBehave complements the Embedder with an Embeddable which represents a runnable facade to the Embedder.

JBehave allows many different ways to configure Embeddable Java classes that allow the parsing and running of textual stories.

JBehave provides two main Embeddable implementations:

...

Code Block
languagejava
titleTraderStoryRunner
collapsetrue
public class TraderStoryRunner {
 
    @Test
    public void runClasspathLoadedStoriesAsJUnit() {
        // Embedder defines the configuration and candidate steps
        Embedder embedder = new TraderEmbedder();
        List<String> storyPaths = ... // use StoryFinder to look up paths
        embedder.runStoriesAsPaths(storyPaths);
    }
 
    @Test
    public void runURLLoadedStoriesAsJUnit() {
        // Embedder defines the configuration and candidate steps
        Embedder embedder = new URLTraderEmbedder();
        List<String> storyPaths = ... // use StoryFinder to look up paths
        embedder.runStoriesAsPaths(storyPaths);
    }
 
}


where the TraderEmbedder/URLTraderEmbedder define the configuration using the loading from the classpath and URL resources, respectively. E.g.:


Code Block
languagejava
titleTraderEmbedder
collapsetrue
public class TraderEmbedder extends Embedder {
 
    @Override
    public EmbedderControls embedderControls() {
        return new EmbedderControls().doIgnoreFailureInStories(true).doIgnoreFailureInView(true);
    }
 
    @Override
    public Configuration configuration() {
        Class<? extends TraderEmbedder> embedderClass = this.getClass();
        return new MostUsefulConfiguration()
            .useStoryLoader(new LoadFromClasspath(embedderClass.getClassLoader()))
            .useStoryReporterBuilder(new StoryReporterBuilder()
                .withCodeLocation(CodeLocations.codeLocationFromClass(embedderClass))
                .withDefaultFormats()
                .withFormats(CONSOLE, TXT, HTML, XML)
                .withCrossReference(new CrossReference()))
            .useParameterConverters(new ParameterConverters()
                    .addConverters(new DateConverter(new SimpleDateFormat("yyyy-MM-dd")))) // use custom date pattern
            .useStepPatternParser(new RegexPrefixCapturingPatternParser(
                            "%")) // use '%' instead of '$' to identify parameters
            .useStepMonitor(new SilentStepMonitor());                               
    }
 
    @Override
    public InjectableStepsFactory stepsFactory() {
        return new InstanceStepsFactory(configuration(), new TraderSteps(new TradingService()), new BeforeAfterSteps());
    }
 
}


Running Remote Stories

JBehave supports running both local and remote stories. To run remote stories, we need to use a URL-based loader with an appropriate remote code location. The difference w.r.t. the local run is minimal:


Code Block
languagejava
titleRemoteTraderStories
collapsetrue
public class RemoteTraderStories extends TraderStories {
 
    @Override
    public Configuration configuration() {
        return super.configuration()
               .useStoryLoader(new LoadFromURL())
               .useStoryReporterBuilder(
                       new StoryReporterBuilder()
                           .withCodeLocation(codeLocationFromURL("http://jbehave.org/reference/examples/stories/"))
                           .withDefaultFormats()
                           .withFormats(CONSOLE, TXT, HTML, XML));
    }
 
    @Override
    protected List<String> storyPaths() {
        // Specify story paths as remote URLs
        String codeLocation = codeLocationFromURL("http://jbehave.org/reference/examples/stories/")
                .toExternalForm();
        return asList(codeLocation + "and_step.story");
    }
 
}


Ignoring Failures Running Stories

By default, the story runners are configured to fail-fast, i.e. the execution will stop at first failed story (but will complete execution of the all the scenarios in the story first). To allow the generation of a complete stories view (reporting how many stories failed), the runners need to be enabled to run stories with ignoreFailureInStories flag set to true. In this way, all stories will run and the failure will be assessed only during the view generation. If any stories failed, the build will fail correspondingly. Should the need to ignore failure in the view arise (although generally not recommended), one can set the ignoreFailureInView flag to true.

View Reports 

https://jbehave.org/reference/stable/reporting-stories.html

...