Elastic Synthetics Journey: Set `playwrightOptions` from parameters

Elastic Observability Synthetics
1

I am writing an Elastic Journey with @elastic/synthetics=1.0.0-beta.43. I've got everything working as expected, however there is one issue.

In my synthetics.config.ts file, I need to pass in the httpCredentials as part of the playwrightOptions:

playwrightOptions: {
  ignoreHTTPSErrors: false,
  httpCredentials: {
    username: 'changeme',
    password: 'changeme',
  },
},

This works fine for testing from my local machine. However, this is insecure for pushing the code to my git repo and also for deployment. I need to be able to provide both the username/password as a parameter or in another secure fashion, but can't determine how to do this, as it appears that @elastic/synthetics handles configuration of the browser object at startup from the playwrightOptions object.

How can I do this?

2

Hello @DougR
I believe workflow defined in these docs should work for you

Regards

3

I've worked my way through this page. The issue is that the following for my synthetics.config.ts:

import type { SyntheticsConfig } from '@elastic/synthetics';

export default env => {
  const config: SyntheticsConfig = {
    params: {
      url: 'https://elastic.github.io/synthetics-demo/',
    },
    playwrightOptions: {
      ignoreHTTPSErrors: false,
      httpCredentials: {
        username: '',
        password: '',
      },
    },
    /**
     * Configure global monitor settings
     */
    monitor: {
      schedule: 10,
      locations: [],
      privateLocations: ['My Private Location'],
    },
    /**
     * Project monitors settings
     */
    project: {
      id: 'myapp',
      url: 'https://elasticsearch.us-east-1.aws.found.io:443',
      space: 'myspace',
    },
  };
  if (env !== 'development') {
    /**
     * Override configuration specific to environment
     * Ex: config.params.url = ""
     */
  }

  config.playwrightOptions.httpCredentials.username = config.params.username;
  config.playwrightOptions.httpCredentials.password = config.params.password;

  return config;
};

yields the following errors:

browser.newContext: httpCredentials.username: expected string, got undefined
    at Function.setupDriver (/Users/e14214/dev/ts/elastic-synthetics-test/projects/alip/node_modules/@elastic/synthetics/src/core/gatherer.ts:65:21)
    at Function.createContext (/Users/e14214/dev/ts/elastic-synthetics-test/projects/alip/node_modules/@elastic/synthetics/src/core/runner.ts:77:20)
    at Runner.runJourney (/Users/e14214/dev/ts/elastic-synthetics-test/projects/alip/node_modules/@elastic/synthetics/src/core/runner.ts:343:21)
    at Runner.run (/Users/e14214/dev/ts/elastic-synthetics-test/projects/alip/node_modules/@elastic/synthetics/src/core/runner.ts:446:11)
    at Command.<anonymous> (/Users/e14214/dev/ts/elastic-synthetics-test/projects/alip/node_modules/@elastic/synthetics/src/cli.ts:132:23)

It appears that the parameters specified from the command line are merged into the config object at a later point in the test, which means that the browser doesn't start with the additional options in the context.

4

Using environment variables to configure this works. I'm not entirely happy with it as a solution, but it works.

5

perhaps something like this could be used but it seems like that API on context is deprecated by playwright

  journey(`My Un-Example Journey ${i}`, ({ page, params, context }) => {
    context.setHTTPCredentials({
      username: params.username,
      password: params.password,
    });

anther solution that will require a pull request is we can apply params to config file just like we do for lightweight yaml with that you will be able to use params in config file like this

playwrightOptions: {
  ignoreHTTPSErrors: false,
  httpCredentials: {
    username: '${username}',
    password: '${password}',
  },
},

do you think it will be useful?

it will work just like it works for lightweight , notice url field is a param

heartbeat.monitors:
- type: http
  name: Todos:Lightweight7
  id: todos-lightweight-2
  enabled: true
  urls: "${url}" 
  schedule: '@every 4m'
  timeout: 16s
  alert:
    status:
6

This would be ideal, if it weren't deprecated. Prior to submitting my original post, I did try to follow the suggestion from the docs to create a new browser context, but it appears that the @elastic/synthetics setup creates an initial browser context and runs in that context. In creating a new context, what happened was that it opened a new window that everything ran in, but nothing validated in. If you have a pattern for doing this, it would certainly be an acceptable item, especially if I could configure this in a beforeAll().

anther solution that will require a pull request is we can apply params to config file just like we do for lightweight yaml with that you will be able to use params in config file like this

playwrightOptions: {
 ignoreHTTPSErrors: false,
 httpCredentials: {
  username: '${username}',
  password: '${password}',
  },
},

do you think it will be useful?

If it were to be done like this, I would think that something similar to monitor.use({}); would be more helpful...like a playwrightOptions.use({}).

At the moment, setting the httpCredentials: {} from environment variables at startup is working for me. And it does resolve the issue where the params values as defined in Synthetics seem to be visible to ANYBODY with access to synthetics, which doesn't seem to be that secure to me.

7

@DougR i appreciate the suggestions. We will try to improve it. I will create an issue to keep track of it.

8

Thank you. Do you have an issue number so I can monitor it?

9

Hello @DougR ,

I tested and following appraoch is already working, if you have params in defined in UI, you can use them as following

playwrightOptions: {
  ignoreHTTPSErrors: false,
  httpCredentials: {
    username: '${username}',
    password: '${password}',
  },
},

Other approach, we did discuss it, right now we are focusing on GA, hopefully we can put forward a proposal as an issue, once i have some time.

I will leave the link here then.

Regards

10

Thanks. Which version is it working in? I may be using an older one.

11

This topic was automatically closed 24 days after the last reply. New replies are no longer allowed.