So, I am looking to dynamicly change the Host, Port, Username and password in a proxy security metadata when building a package.
I am using some apis calls that require the usage of a proxy but the proxy on the windows VM (virtual machine) where I am developing my process and the proxy of the server where my work will be deployed aren't the same.
The proxy on my VM use an Host, a Port and need a username and a password but the proxy on the server only need a different Host and a different Port.
So I wonder if I can change these values dynamicly so I don't have to externalize my username and my password in the package.
I tried to use environnement variables and use them in xDi but I can't figure out how to do this.
Can you help me with this ?
Best regards,
Best Answer
A
Audric FREY
said
about 1 hour ago
Good afternoon,
Yes, this is exactly what the metadata externalization mechanism is designed for, and it lets you avoid hardcoding or externalizing the username/password in the package itself.
**1) Externalize the Proxy metadata attributes**
In your Proxy metadata (Host, Port, Username, Password), some attributes are externalized by default depending on the technology, but you can also explicitly externalize any attribute that isn't externalized by default:
- Open the Proxy metadata in Designer.
- In the metadata editor, select the node containing the property you want to externalize (Host, Port, Username, Password).
- Mark it as externalized (right-click > Externalize, or via the property's context menu depending on your Designer version).
Once externalized, these values are no longer hardcoded in the generated package: they become placeholders that must be filled in with actual values at build/deploy time, per environment.
**2) Create one Metadata Configuration per environment**
A Metadata Configuration is a named container holding the actual values for these externalized properties, specific to one environment. This is exactly the mechanism to solve your problem: you can have one configuration for your local/dev VM (with Host, Port, Username, Password for your local proxy) and a different configuration for the target server (with only Host and Port set, leaving Username/Password empty since that proxy doesn't require them).
You manage these configurations either in xDI Analytics (Administration > Configurations tab) for production environments, or as local configuration files if you're driving builds by scripts/CLI.
Important: this means your username and password are never stored inside the package/delivery itself. They only exist in the configuration used at build or deploy time, which you can keep out of source control if needed, or manage centrally in Analytics.
**3) Select the configuration at build time via CLI**
When generating deliveries, you point to a specific configuration file with the buildDelivery Designer CLI command, using the -confFile parameter:
Each .conf file contains the actual values for your externalized attributes (Host/Port/Username/Password) for that specific environment. If a given environment's proxy doesn't need Username/Password, you simply leave those externalized attributes empty or unset in that configuration file.
You can also validate that a given configuration file has everything needed for a package with the validateConfFile command, and generate an initial template of the configuration (with all externalized attributes listed) using extractPackageInfo -extract conf.
1. Externalize Host, Port, Username, Password on your Proxy metadata.
2. Create two Metadata Configurations (e.g. "local-dev" and "prod-server"), each with the values matching that environment's proxy.
3. Build/generate your delivery using buildDelivery -confFile pointing to the correct configuration for the target environment.
This way you never need environment variables inside xDI itself for this, and your credentials stay out of the package, only living in the configuration used to build for a given environment.
Let us know if you'd like a hand setting up the externalization on your specific Proxy metadata object.
1 Comment
A
Audric FREY
said
about 1 hour ago
Answer
Good afternoon,
Yes, this is exactly what the metadata externalization mechanism is designed for, and it lets you avoid hardcoding or externalizing the username/password in the package itself.
**1) Externalize the Proxy metadata attributes**
In your Proxy metadata (Host, Port, Username, Password), some attributes are externalized by default depending on the technology, but you can also explicitly externalize any attribute that isn't externalized by default:
- Open the Proxy metadata in Designer.
- In the metadata editor, select the node containing the property you want to externalize (Host, Port, Username, Password).
- Mark it as externalized (right-click > Externalize, or via the property's context menu depending on your Designer version).
Once externalized, these values are no longer hardcoded in the generated package: they become placeholders that must be filled in with actual values at build/deploy time, per environment.
**2) Create one Metadata Configuration per environment**
A Metadata Configuration is a named container holding the actual values for these externalized properties, specific to one environment. This is exactly the mechanism to solve your problem: you can have one configuration for your local/dev VM (with Host, Port, Username, Password for your local proxy) and a different configuration for the target server (with only Host and Port set, leaving Username/Password empty since that proxy doesn't require them).
You manage these configurations either in xDI Analytics (Administration > Configurations tab) for production environments, or as local configuration files if you're driving builds by scripts/CLI.
Important: this means your username and password are never stored inside the package/delivery itself. They only exist in the configuration used at build or deploy time, which you can keep out of source control if needed, or manage centrally in Analytics.
**3) Select the configuration at build time via CLI**
When generating deliveries, you point to a specific configuration file with the buildDelivery Designer CLI command, using the -confFile parameter:
Each .conf file contains the actual values for your externalized attributes (Host/Port/Username/Password) for that specific environment. If a given environment's proxy doesn't need Username/Password, you simply leave those externalized attributes empty or unset in that configuration file.
You can also validate that a given configuration file has everything needed for a package with the validateConfFile command, and generate an initial template of the configuration (with all externalized attributes listed) using extractPackageInfo -extract conf.
1. Externalize Host, Port, Username, Password on your Proxy metadata.
2. Create two Metadata Configurations (e.g. "local-dev" and "prod-server"), each with the values matching that environment's proxy.
3. Build/generate your delivery using buildDelivery -confFile pointing to the correct configuration for the target environment.
This way you never need environment variables inside xDI itself for this, and your credentials stay out of the package, only living in the configuration used to build for a given environment.
Let us know if you'd like a hand setting up the externalization on your specific Proxy metadata object.
ELIAS Axel
Good afternoon everybody,
So, I am looking to dynamicly change the Host, Port, Username and password in a proxy security metadata when building a package.
I am using some apis calls that require the usage of a proxy but the proxy on the windows VM (virtual machine) where I am developing my process and the proxy of the server where my work will be deployed aren't the same.
The proxy on my VM use an Host, a Port and need a username and a password but the proxy on the server only need a different Host and a different Port.
So I wonder if I can change these values dynamicly so I don't have to externalize my username and my password in the package.
I tried to use environnement variables and use them in xDi but I can't figure out how to do this.
Can you help me with this ?
Best regards,
Good afternoon,
Yes, this is exactly what the metadata externalization mechanism is designed for, and it lets you avoid hardcoding or externalizing the username/password in the package itself.
**1) Externalize the Proxy metadata attributes**
In your Proxy metadata (Host, Port, Username, Password), some attributes are externalized by default depending on the technology, but you can also explicitly externalize any attribute that isn't externalized by default:
- Open the Proxy metadata in Designer.
- In the metadata editor, select the node containing the property you want to externalize (Host, Port, Username, Password).
- Mark it as externalized (right-click > Externalize, or via the property's context menu depending on your Designer version).
Once externalized, these values are no longer hardcoded in the generated package: they become placeholders that must be filled in with actual values at build/deploy time, per environment.
Documentation: Externalize Metadata Values
https://www.semarchy.com/doc/semarchy-xdi/xdi/latest/Design/data/externalize-metadata-values.html
**2) Create one Metadata Configuration per environment**
A Metadata Configuration is a named container holding the actual values for these externalized properties, specific to one environment. This is exactly the mechanism to solve your problem: you can have one configuration for your local/dev VM (with Host, Port, Username, Password for your local proxy) and a different configuration for the target server (with only Host and Port set, leaving Username/Password empty since that proxy doesn't require them).
You manage these configurations either in xDI Analytics (Administration > Configurations tab) for production environments, or as local configuration files if you're driving builds by scripts/CLI.
Documentation: Manage Metadata Configurations
https://www.semarchy.com/doc/semarchy-xdi/xdi/2023.2/Production/manage-metadata.html
Important: this means your username and password are never stored inside the package/delivery itself. They only exist in the configuration used at build or deploy time, which you can keep out of source control if needed, or manage centrally in Analytics.
**3) Select the configuration at build time via CLI**
When generating deliveries, you point to a specific configuration file with the buildDelivery Designer CLI command, using the -confFile parameter:
buildDelivery -package "D:/Built Items/myPackage01.pck" -buildmode substitution -confFile "D:/Configuration Files/confA.conf"
So for your case you would have something like:
buildDelivery -package "D:/Built Items/myPackage01.pck" -confFile "D:/Configuration Files/local-proxy.conf"
buildDelivery -package "D:/Built Items/myPackage01.pck" -confFile "D:/Configuration Files/server-proxy.conf"
Each .conf file contains the actual values for your externalized attributes (Host/Port/Username/Password) for that specific environment. If a given environment's proxy doesn't need Username/Password, you simply leave those externalized attributes empty or unset in that configuration file.
You can also validate that a given configuration file has everything needed for a package with the validateConfFile command, and generate an initial template of the configuration (with all externalized attributes listed) using extractPackageInfo -extract conf.
Documentation: Designer CLI command reference (buildDelivery, validateConfFile, extractPackageInfo)
https://www.semarchy.com/doc/semarchy-xdi/xdi/latest/Manage/designer-cli/commands.html
**Summary of the flow:**
1. Externalize Host, Port, Username, Password on your Proxy metadata.
2. Create two Metadata Configurations (e.g. "local-dev" and "prod-server"), each with the values matching that environment's proxy.
3. Build/generate your delivery using buildDelivery -confFile pointing to the correct configuration for the target environment.
This way you never need environment variables inside xDI itself for this, and your credentials stay out of the package, only living in the configuration used to build for a given environment.
Let us know if you'd like a hand setting up the externalization on your specific Proxy metadata object.
Audric FREY
Good afternoon,
Yes, this is exactly what the metadata externalization mechanism is designed for, and it lets you avoid hardcoding or externalizing the username/password in the package itself.
**1) Externalize the Proxy metadata attributes**
In your Proxy metadata (Host, Port, Username, Password), some attributes are externalized by default depending on the technology, but you can also explicitly externalize any attribute that isn't externalized by default:
- Open the Proxy metadata in Designer.
- In the metadata editor, select the node containing the property you want to externalize (Host, Port, Username, Password).
- Mark it as externalized (right-click > Externalize, or via the property's context menu depending on your Designer version).
Once externalized, these values are no longer hardcoded in the generated package: they become placeholders that must be filled in with actual values at build/deploy time, per environment.
Documentation: Externalize Metadata Values
https://www.semarchy.com/doc/semarchy-xdi/xdi/latest/Design/data/externalize-metadata-values.html
**2) Create one Metadata Configuration per environment**
A Metadata Configuration is a named container holding the actual values for these externalized properties, specific to one environment. This is exactly the mechanism to solve your problem: you can have one configuration for your local/dev VM (with Host, Port, Username, Password for your local proxy) and a different configuration for the target server (with only Host and Port set, leaving Username/Password empty since that proxy doesn't require them).
You manage these configurations either in xDI Analytics (Administration > Configurations tab) for production environments, or as local configuration files if you're driving builds by scripts/CLI.
Documentation: Manage Metadata Configurations
https://www.semarchy.com/doc/semarchy-xdi/xdi/2023.2/Production/manage-metadata.html
Important: this means your username and password are never stored inside the package/delivery itself. They only exist in the configuration used at build or deploy time, which you can keep out of source control if needed, or manage centrally in Analytics.
**3) Select the configuration at build time via CLI**
When generating deliveries, you point to a specific configuration file with the buildDelivery Designer CLI command, using the -confFile parameter:
buildDelivery -package "D:/Built Items/myPackage01.pck" -buildmode substitution -confFile "D:/Configuration Files/confA.conf"
So for your case you would have something like:
buildDelivery -package "D:/Built Items/myPackage01.pck" -confFile "D:/Configuration Files/local-proxy.conf"
buildDelivery -package "D:/Built Items/myPackage01.pck" -confFile "D:/Configuration Files/server-proxy.conf"
Each .conf file contains the actual values for your externalized attributes (Host/Port/Username/Password) for that specific environment. If a given environment's proxy doesn't need Username/Password, you simply leave those externalized attributes empty or unset in that configuration file.
You can also validate that a given configuration file has everything needed for a package with the validateConfFile command, and generate an initial template of the configuration (with all externalized attributes listed) using extractPackageInfo -extract conf.
Documentation: Designer CLI command reference (buildDelivery, validateConfFile, extractPackageInfo)
https://www.semarchy.com/doc/semarchy-xdi/xdi/latest/Manage/designer-cli/commands.html
**Summary of the flow:**
1. Externalize Host, Port, Username, Password on your Proxy metadata.
2. Create two Metadata Configurations (e.g. "local-dev" and "prod-server"), each with the values matching that environment's proxy.
3. Build/generate your delivery using buildDelivery -confFile pointing to the correct configuration for the target environment.
This way you never need environment variables inside xDI itself for this, and your credentials stay out of the package, only living in the configuration used to build for a given environment.
Let us know if you'd like a hand setting up the externalization on your specific Proxy metadata object.
-
Set webservice password dynamically in XDI
-
Unable to use "PATCH" as HTTP verb in a REST API call
-
SQL SERVER INTEGRATED SECURITY FOR RUNTIME LOGS
-
Microsoft SQL server "Could not establish a secure SQL Server connection using SSL encryption"
-
how to import SQLITE database
-
Chiffrement de fichier
-
Azure Service Bus - possible to connect to a topic?
-
Export Log
-
Error HttpRest metadata when reversing API
-
API key authentication instead of basic authentication
See all 18 topics