I am using Remote URL option which reaches out to remote web server to retrieve needed data. Simply using this,
https://rundeck:test#myserver.com works. However, I would like to pass the password in secure way so...
Option 1 uses 'Secure pass input' and pass is retrieved from key storage, however the password is then not added to the remote URL in
Option 2, which uses Remote URL, https://rundeck:${option.password.value}#myserver.com. My remote servers receives the password as ${option.password.value} and not the actual password value retrieved in Option 1. I understand that Secure Remote Authentication can't be used in Options, however i don't believe I have seen restrictions on what I want to do with Secure † Password input in Rundeck's docs.
Lastly, typing in the password in Secure † Password input option does add the password to the mentioned URL above. I have tested and verified that ${option.password.value} value can be passed in a job's step, that part works. However, it does not appear to work in cascading options.
Currently, secure options values are not expanded as a part of remote options, you can suggest it here (similar to this). Alternatively, you can create a specific custom plugin for that.
Another approach is to design a workflow that uses the HTTP Workflow Step Plugin (passing your secure password as a part of the authentication in the URL) to access the web service + JQ Filter to generate the desired data, then in another/step you can get that data using data variables.
Like this:
- defaultTab: nodes
description: ''
executionEnabled: true
id: 7f34f7ff-c4a3-4616-a2aa-0df491450366
loglevel: INFO
name: HTTP
nodeFilterEditable: false
options:
- name: mypass
secure: true
storagePath: keys/password
valueExposed: true
plugins:
ExecutionLifecycle: null
scheduleEnabled: true
sequence:
commands:
- configuration:
authentication: None
checkResponseCode: 'false'
method: GET
printResponse: 'true'
printResponseToFile: 'false'
proxySettings: 'false'
remoteUrl: https://user:${option.mypass}#myserver.com
sslVerify: 'true'
timeout: '30000'
nodeStep: false
plugins:
LogFilter:
- config:
filter: .
logData: 'true'
prefix: result
type: json-mapper
type: edu.ohio.ais.rundeck.HttpWorkflowStepPlugin
- exec: echo "name 2 is ${data.Name2}"
keepgoing: false
strategy: node-first
uuid: 7f34f7ff-c4a3-4616-a2aa-0df491450366
Related
I tried to configure Elasticsearch for monolog as mentioned here but the problem is that I don't find any way to pass my username and password for Elasticsearch since the ElasticsearchLogstashHandler service only takes an endpoint as input.
here's the service that I created:
elasticsearch_logstash_handler:
class: Symfony\Bridge\Monolog\Handler\ElasticsearchLogstashHandler
arguments: [ '%ELASTIC_SEARCH_ENDPOINT%']
I tried to put username and password in the URL (username:password#url) but since the password contains special characters it doesn't work this way.
thank you for sharing your ideas.
I have an entire API deployed and accessible with Swagger UI. It uses Basic Auth over HTTPS, and one can easily hit the Authorize button and enter credentials and things work great with the nice Try it out! feature.
However, I would like to make a public sandboxed version of the API with a shared username and password, that is always authenticated; that is, no one should ever have to bring up the authorization dialog to enter credentials.
I tried to enter an authorization based on the answer from another Stack Overflow question by putting the following code inside a script element on the HTML page:
window.swaggerUi.load();
swaggerUi.api.clientAuthorizations.add("key",
new SwaggerClient.ApiKeyAuthorization(
"Authorization", "Basic dXNlcm5hbWU6cGFzc3dvcmQ=", "header"));
However, when I hit the Try it out! button the authorization is not used.
What would be the proper way to go about globally setting the auth header on all endpoints, so that no user has to enter the credentials manually?
(I know that might sound like a weird question, but like I mention, it is a public username/password.)
If you use Swagger UI v.3.13.0 or later, you can use the following methods to authorize the endpoints automatically:
preauthorizeBasic – for Basic auth
preauthorizeApiKey – for API keys and OpenAPI 3.x Bearer auth
To use these methods, the corresponding security schemes must be defined in your API definition. For example:
openapi: 3.0.0
...
components:
securitySchemes:
basicAuth:
type: http
scheme: basic
api_key:
type: apiKey
in: header
name: X-Api-Key
bearerAuth:
type: http
scheme: bearer
security:
- basicAuth: []
- api_key: []
- bearerAuth: []
Call preauthorizeNNN from the onComplete handler, like so:
// index.html
const ui = SwaggerUIBundle({
url: "https://my.api.com/swagger.yaml",
...
onComplete: function() {
// Default basic auth
ui.preauthorizeBasic("basicAuth", "username", "password");
// Default API key
ui.preauthorizeApiKey("api_key", "abcde12345");
// Default Bearer token
ui.preauthorizeApiKey("bearerAuth", "your_bearer_token");
}
})
In this example, "basicAuth", "api_key", and "bearerAuth" are the keys name of the security schemes as specified in the API definition.
I found a solution, using PasswordAuthorization instead of ApiKeyAuthorization.
The correct thing to do is to add the following line into the onComplete handler:
swaggerUi.api.clientAuthorizations.add("basicAuth",
new SwaggerClient.PasswordAuthorization(
"8939927d-4b8a-4a69-81e4-8290a83fd2e7",
"fbb7a689-2bb7-4f26-8697-d15c27ec9d86"));
swaggerUi is passed to the callback so this is the value to use. Also, make sure the name of your auth object matches the name in the YAML file.
I'm using Google for authenticating, like following:
let credential = Credential.google(token: "<SOME-HASH-HERE>.apps.googleusercontent.com")
SyncUser.authenticate(with: credential, server: serverURL, timeout: 60) { [weak self] user, error in
guard nil == error else {
print("error while authenticating: \(error!)")
return
}
…
}
It gives an error 400. After some debugging I found more info about the problem, but still not sure what is wrong with that. So response looks like this:
{
"invalid_params":[
{
"name":"provider",
"reason":"Unknown provider!"
}
],
"status":400,
"type":"https://realm.io/docs/object-server/problems/invalid-parameters",
"title":"Your request parameters did not validate!",
"code":601
}
Here is request body:
{
"provider":"google",
"app_id":"com.blabla.bla-bla-bla",
"data":"<SOME-HASH-HERE>.apps.googleusercontent.com"
}
I took auth code from example from official documentation, and I'm using latest Realm framework.
I also checked authentication using Facebook, but it gives same error.
I checked configuration.yml file on server, and did uncomment google and facebook, put required details, and restart system. Not helping.
Does anyone experience same problem?
PS: configuration.yml(only part with providers):
# Realm Object Server Configuration
#
# For each possible setting, the commented out values are the default values
# unless another default is mentioned explicitly.
#
# Paths specified in this file can be either absolute or relative.
# Relative paths are relative to the current working directory.
providers:
## Providers of authentication tokens. Each provider has a configuration
## object associated with it. If a provider is included here and its
## configuration is valid, it will be enabled.
## Possible providers: cloudkit, debug, facebook, realm, password
## Providers 'realm' and 'password' are always enabled:
## - The 'realm' provider is used to derive access tokens from a refresh token.
## - The 'password' provider is required for the dashboard to work. It supports
## authentication through username/password and uses a PBKDF2 implementation.
## This enables authentication via a Google Sign-In access token for a
## specific app.
google:
## The client ID as retrieved when setting up the app in the Google
## Developer Console.
clientId: '<SOME-HASH-HERE>.apps.googleusercontent.com'
## This enables authentication via a Facebook access token for a specific app.
## This provider needs no configuration (uncommenting the next line enables it).
facebook: {}
After I made changes in that file I called
sudo service realm-object-server restart
And just to be sure I also reboot system.
Unfortunately, there is a bug in the sample configuration.yml file shipped with Realm Object Server which I suspect you're hitting. The providers: section in the configuration file should live under the auth: section (instead of inside the network: section where it lives in the shipped file). The fix is to simply move the relevant providers configuration to live under the auth: key.
We have a fix ready for this bug which will be part of the next release of Realm Object Server.
Here's a sample snippet showing the complete auth: section with the fix:
# Realm Object Server Configuration
#
# For each possible setting, the commented out values are the default values
# unless another default is mentioned explicitly.
#
# Paths specified in this file can be either absolute or relative.
# Relative paths are relative to the current working directory.
auth:
## The path to the public and private keys (in PEM format) that will be used
## to validate identity tokens sent by clients.
## These configuration options are MANDATORY.
public_key_path: /etc/realm/token-signature.pub
private_key_path: /etc/realm/token-signature.key
providers:
## Providers of authentication tokens. Each provider has a configuration
## object associated with it. If a provider is included here and its
## configuration is valid, it will be enabled.
## Possible providers: cloudkit, debug, facebook, realm, password
## Providers 'realm' and 'password' are always enabled:
## - The 'realm' provider is used to derive access tokens from a refresh token.
## - The 'password' provider is required for the dashboard to work. It supports
## authentication through username/password and uses a PBKDF2 implementation.
## This enables authentication via a Google Sign-In access token for a
## specific app.
google:
## The client ID as retrieved when setting up the app in the Google
## Developer Console.
clientId: '<SOME-HASH-HERE>.apps.googleusercontent.com'
## This enables authentication via a Facebook access token for a specific app.
## This provider needs no configuration (uncommenting the next line enables it).
facebook: {}
Is there a way to configure user roles with SaltStack for MongoDB 3? I see that the mongodb module has relevant role management functions, but the mongodb_user state does not refer to roles anywhere.
Yes, there certainly is!
You'll want to use the Mongodb module, and execute it from a state using module.run.
so, for example, if you want to manage the roles of a user 'TestUser', you'd create 'manage_mongo_roles.sls', and it will contain states like the following:
manage_mongo_roles:
module.run:
- name: mongodb.user_grant_roles
- m_name: TestUser
- roles: ["admin"]
- database: admin
- user: admin
- password: ''
- host: localhost
- port: 27017
The 'name' paramater for the module MUST be prefaced with a m_, so that the state knows to pass this to the module and not use it as the name of the module to be executed.
Also note that the role MUST be of the format
["role"]
The documentation indicates that, if run from the salt CLI it should be contained in single quotes, like so:
'["role"]'
but doing so in the module.run state WILL cause it to fail, and return with a less than descriptive error message.
This question may have been asked before. I have searched for answers, but I haven't found what I was looking for.
In Symfony 2.3, is there a way to disable the logger for specific requests? I mean, I am using a SOAP service for my project. When I send a request to login, the username and password are dumped straight as plain text into the log file. Is there a way to stop logging this kind of specific requests?
For example, when I send a request for login, the logger should be disabled, but for all other request it works again. Is this possible?
depending if your are in Prod or Dev environement but everything is in config.yml or config_dev.yml :
to disable logging just remove monolog configuration like this :
monolog:
handlers:
main:
type: stream
path: "%kernel.logs_dir%/%kernel.environment%.log"
level: debug
console:
type: console
bubble: false
# uncomment to get logging in your browser
# you may have to allow bigger header sizes in your Web server configuration
#firephp:
# type: firephp
# level: info
#chromephp:
# type: chromephp
# level: info
but in my opinion , you shouln't do this because logging allows you to improve significantly your code !
Logging except for a specific service :
You need to create a specific log channel for your service as described there :
http://symfony.com/doc/current/cookbook/logging/channels_handlers.html
and there :
http://symfony.com/doc/current/reference/dic_tags.html#dic-tags-monolog
you ll be able to separate your soap log from others and eventually send it to null