Merge branch 'mendix:development' into 10.18

content/en/docs/appstore/use-content/platform-supported-content/modules/oidc.md

@@ -40,6 +40,7 @@ Alternatives to using OIDC SSO for managing single sign-on are:
 * **Xcelerator apps:** Your Siemens Xcelerator app is designed to be integrated with Siemens' SAM IdP.  The Siemens SAM IdP supports the OIDC protocol and allows your app to delegate both authentication (login) and authorization (roles).
 * **Works with Responsive web app and PWA:** OIDC SSO module supports both responsive web apps and progressive web apps (PWA), ensuring seamless functionality in both offline and online modes for PWAs. If you are building a native mobile app, you need to use [Mobile SSO](https://marketplace.mendix.com/link/component/223516) module for your app. For more information, see [Building a Responsive Web App](/quickstarts/responsive-web-app/), [Progressive Web App](/refguide/mobile/introduction-to-mobile-technologies/progressive-web-app/), and [Native Mobile](/refguide/mobile/introduction-to-mobile-technologies/native-mobile/).
 * **API security:** If your app exposes APIs, such as an OData API, it is best security practice to use OAuth Access Tokens (also known as bearer tokens or JWT tokens) instead of Basic Authentication or API keys. You can use the OIDC SSO module to validate these Access Tokens and check if they have right authorization (i.e., the right OAuth scopes) for accessing your API endpoint. For example, you may want to allow a specific user or client to perform a GET (read) request but not a POST or PATCH (write) request. The OIDC module supports processing Access Tokens obtained via both SSO and the OAuth client credential grant.
+* **App-initiated logout at the IdP:** As a counterpart to logging in via SSO, it is possible to include a logout button in your app that also logs the end user out from the IdP.
 
 ### Features and Limitations
 
@@ -97,6 +98,7 @@ For readers with more knowledge of the OAuth and OIDC protocol:
 * Supports response_mode=query and response_mode=form_post
 * Helps you implement an OAuth Resource Server that receives an Access Token which is obtained by a client via either Authorization Code grant or Client Credential grant.
 * When the OIDC SSO module secures an API with the Client Credential grant, the `sub` as claim (which contains either user-id or client-id) should always be available in the access token as per [RFC 9068](https://datatracker.ietf.org/doc/html/rfc9068#name-data-structure).  If it is not included, the module will look for `client_id`. To be compliant with Microsoft's Entra ID and Okta, it will use `app_id` or `cid` as alternatives to `client_id`. Any of these client identifiers are used to create a user in the Mendix application, allowing the Mendix security model to apply not only to users (human identities) but also to clients (machine identities).
+* Supports [OpenID Connect RP-Initiated Logout 1.0](https://openid.net/specs/openid-connect-rpinitiated-1_0.html). When sending a logout request to the IdP's `end_session_endpoint`, the parameters `id_token_hint` and `post_logout_redirect_uri` are supported for the logout request.
 
 #### Limitations
 
@@ -880,9 +882,9 @@ The Deep Link module does not have full support for multiple IdPs, so it can onl
 
 ### Logging Out
 
-A standard logout action will end an end-user's Mendix session, but will not end their SSO session. To perform an SSO logout, also known as Single Log Out (SLO), use the nanoflow `ACT_Logout`, which will redirect your user to the IdP's “end session endpoint” if configured.
+A standard log out action will end an end-user's Mendix session, but will not end their SSO session. If you want to allow your app's end-users to log out, you can add a menu item or button that call the nanoflow `ACT_Logout`. This nanoflow will end the local session in your app and, if applicable, request the connected IdP to terminate the user's session there as well.
 
-To do this, add a menu item or button for your end-users that calls the nanoflow `ACT_Logout`.
+During this process, the user's browser will be redirected to the IdP, logging them out of both your Mendix app and the IdP. Optionally, you can configure the IdP to redirect the user to the `post_logout_redirect_uri` after log out, allowing the user to return to your app. 
 
 ### Using ACR to Request Authentication Method
 

content/en/docs/appstore/use-content/platform-supported-content/modules/snowflake/mendix-data-loader.md

@@ -49,8 +49,6 @@ Once the Mendix Data Loader is deployed, follow these steps to configure and use
 6. To view the configuration status, click the **Authentication Configuration** tab.
 7. To set up authentication, click **Edit**, and then provide the required information based on the selected authentication type:
 
-    [//]: # (<!-- markdownlint-disable no-space-in-emphasis -->)
-
     * For basic authentication, enter the following information:
         * **Username** – A username for basic authentication into the OData resource in your Mendix application
         * **Password** – A password for basic authentication into the OData resource in your Mendix application
@@ -61,8 +59,6 @@ Once the Mendix Data Loader is deployed, follow these steps to configure and use
         * **Allowed Scopes** – Allowed and custom scopes configured on the client from your OAuth provider
         * **Access Token Validity** – Duration (in seconds) for which the access token is valid
 
-    [//]: # (<!-- markdownlint-enable no-space-in-emphasis -->)
-
 8. Click **Generate Script**.
 9. Click **Back** to return to the **Details** page.
 10. Click the **Ingestion Configuration** tab to set up your ingestion destination table.
@@ -102,6 +98,47 @@ To view all ingestion jobs associated with a specific data source in Snowflake,
 SELECT * FROM core.ingestion_job WHERE DATASOURCE_ID = '1234abcd' ORDER BY CREATED_DATE_TIME DESC;
 ```
 
+## Programmatically Triggering an Ingestion Job From a Mendix App {#trigering-jobs}
+
+Programmatically triggering an ingestion job can meet data ingestion requirements where a scheduled task may not, for example in the following use cases:
+
+* Waiting for a last submission to be submitted to a Mendix app before data ingestion occurs.
+* Starting data ingestion when the load on the Mendix app is the lowest.
+
+### Prerequisites
+
+* A fully configured data source in the Mendix Data Loader
+* A Mendix app equipped with the Snowflake REST SQL connector
+* An authenticated user that is allowed to trigger stored procedures
+
+### Triggering the Ingestion
+
+To trigger an ingestion job programmatically, use the `ExecuteStatement` operation available in the [Snowflake REST SQL connector](/appstore/connectors/snowflake/snowflake-rest-sql/).
+
+1. Obtain the Snowflake data source ID by performing the following steps:
+
+    1. In the Snowflake environment, open the Mendix Data Loader by clicking **Data Products** > **Apps** > **Mendix Data Loader**.
+    2. Open the application by clicking the `MENDIX_DATA_LOADER` tab.
+    3. Click **View** by the configured data source.
+    4. Copy the value for the `ID` key.
+
+2. In the Snowflake REST SQL connector, use the `ExecuteStatement` operation to execute the following statement:
+
+```sql
+CALL {NAME_OF_THE_MENDIX_DATA_LOADER}.MX_FUNCTIONS.RUN_INGESTION_JOB('{DATASOURCE_ID}','');
+```
+
+where you must specify the following variables:
+
+* `{NAME_OF_THE_MENDIX_DATA_LOADER}` - The default name for the Mendix Data Loader is `MENDIX_DATA_LOADER`
+* `{DATASOURCE_ID}` - Required; the data source ID that you obtained in step 1
+
+For example, for a data source with the ID *40FJYP9D*, the resulting statement would be:
+
+```sql
+CALL MENDIX_DATA_LOADER.MX_FUNCTIONS.RUN_INGESTION_JOB('40FJYP9D','');
+```
+
 ## Verifying the Access Token
 
 When using OAuth authentication with the Mendix Data Loader, it is crucial to verify the access token received by your Mendix application. This verification process ensures the token's authenticity and integrity, protecting your application from unauthorized access attempts.

content/en/docs/appstore/use-content/platform-supported-content/modules/snowflake/snowflake-rest-sql.md

@@ -117,6 +117,10 @@ Your custom microflows should consist of the following:
 
 This approach allows you to achieve asynchronous behavior while leveraging the Snowflake REST SQL Connector.
 
+#### Programmatic Triggering of Ingestion Jobs
+
+The Snowflake REST SQL connector can be used to trigger data ingestion jobs with an SQL statement. For more information, see [Mendix Data Loader: Programmatically Triggering an Ingestion Job From a Mendix App](/appstore/modules/snowflake/mendix-data-loader/#trigering-jobs).
+
 ## Technical Reference
 
 To help you work with the Snowflake REST SQL connector, the following sections of this document list the available entities, enumerations, and activities that you can use in your application.

content/en/docs/control-center/security/security.md

@@ -0,0 +1,58 @@
+---
+title: "Security Settings in Control Center"
+linktitle: "Settings"
+url: /control-center/security-settings/
+description: "Describes the Settings page in the Security category in Control Center."
+weight: 10
+no_list: false
+---
+
+{{% alert color="info" %}}
+A member in Control Center means a user of the Mendix platform who participates in the development process. It does not mean an end-user of an app built in the Mendix Platform.
+{{% /alert %}}
+
+## Introduction 
+
+The **Settings** page in the **Security** category in Control Center allows you to configure the security settings, manage the single sign-on configurations, and view the security history of your company.
+
+## Security Settings Tab
+
+### Password Policy
+
+With the **Password Policy** setting, you can set the password expiration policy for all company members. If you do not want the passwords to expire, toggle **Passwords of company members never expire** to **On**.
+
+### Email Signing {#disable-enable-digital-signing-emails}
+
+The Mendix Platform digitally signs the content of emails from senders [[email protected]](mailto:[email protected]) and [[email protected]](mailto:[email protected]). By digitally signing the content of an email, Mendix provides assurance to the recipient of the email that the content of an email has not been altered in transit. For reasons of security, this feature is enabled by default. However, if digitally signing the content of an email interferes with the delivery of that email to the recipient, a Mendix Admin can disable this feature for emails sent to receivers in the company domains. For more information, see the [Why Would You Want to Disable the Digital Signing of Email Content?](#why-disable-email-signing) section below.
+
+To disable the digital signing of emails, turn off the toggle. To enable the digital signing of emails, turn on the toggle. This setting has an effect on the emails sent to all the [email domains claimed by your company](/control-center/company-settings/#company-email-domains).
+
+#### Why Would You Want to Disable the Digital Signing of Email Content? {#why-disable-email-signing}
+
+Digital signing of email content contributes to security, so why would you want to disable the digital signing of email content sometimes?
+
+Digital signing might interfere with other email safety measures like “External Email Warning”. This feature might add a customized HTML warning to the email. Since Mendix emails cannot be altered, some email servers will wrap the original message in a blank email and add the original email as an attachment. This is not beneficial for the experience of the user and will make the emails look suspicious, impacting user engagement. Also, it makes searching for emails with specific text content more difficult for users.
+
+### Application Data Replication {#application-data-replication}
+
+{{% alert color="info" %}}
+The application data replication setting only affects apps and environments that have not been provisioned yet.
+
+This feature is only available to [premium customers](/developerportal/deploy/mendix-cloud-deploy/#additional-resources).
+{{% /alert %}}
+
+By default, Mendix provides premium customers with an SLA which includes high-availability and disaster recovery measures. This means that your application data (file storage and database backups) is replicated to other availability zones within the region and also to a secondary region so that you can still access your data in case of an outage in the primary region.
+
+Secondary regions are, wherever possible, in the same political region as the primary region. However this is not always possible.You can find which secondary regions are used for each primary region in the [Data Location](/developerportal/operate/backups/#data-location) section of *Backups*.
+
+If you want your data to remain in the primary region and not be replicated to a secondary region, click **Deactivate** to deactivate application data replication. You will have to confirm that you accept the impact this has on the service level agreement you have with Mendix regarding disaster recovery and SOC2 compliance. Once you have made this change, all new environments which are provisioned will not replicate data to other regions.
+
+You can turn application data replication back on by clicking **Activate**. 
+
+## Single Sign-On Tab
+
+On the **Single Sign-On** tab, you can set up an identity federation between the Mendix Platform and your corporate identity provider. We call this feature *Bring Your Own Identity Provider (BYOIDP)* and you can find more information in [How to Set Up an SSO (BYOIDP)](/control-center/security/set-up-sso-byoidp/).
+
+## Security History Tab
+
+On the **Security History** tab, you can view a detailed history of changes to application data replication settings, including when the changes were made and by whom.

content/en/docs/deployment/mendix-cloud-deploy/_index.md

@@ -203,6 +203,10 @@ Fallback ensures that the data in your database is automatically copied to a dat
 
 The connections between AZs are low latency. However, the implementation of these features means that your monitoring may indicate that apps deployed to Mendix Cloud under a Premium plan suffer an additional latency of a few milliseconds compared with apps deployed using a Standard plan. For a well-designed app, this difference is not noticeable to end-users. 
 
+#### Application Data Replication
+
+With a premium plan, you can replicate application data in Mendix Cloud to another region for security and disaster recovery purposes. For more information, see the [Application Data Replication](/control-center/security-settings/#application-data-replication) section in *Security Settings in Control Center*.
+
 #### Regional Fallback{#regional-fallback}
 
 You can also purchase a Premium Plus plan, which provides all the features of the Premium plan, with the addition of Regional Fallback.

content/en/docs/refguide/mobile/distributing-mobile-apps/building-native-apps/bitrise.md

@@ -33,7 +33,7 @@ Before starting this guide, make sure you have completed the following prerequis
 * Signed up as an [Android developer](https://play.google.com/console/signup)
 * Created a Keystore [with Android Studio](https://developer.android.com/studio/publish/app-signing#generate-key) or [with Java](https://docs.oracle.com/cd/E19509-01/820-3503/ggfen/index.html)
 
-## Set Up Your Build Project
+## Set Up Your Build Project {#set-up-your-build-project}
 
 To set up your build project, do the following:
 
@@ -117,13 +117,14 @@ This step will install the dependencies required for iOS.
 
 1. Add a new step before the step **Xcode Archive** (after Run CocoaPods install).
 1. Choose **Manage iOS Code Singing** from the list of steps.
+1. Set the distribution method to the method selected in [section 3](#set-up-your-build-project).
 1. Save changes.
 
 Bitrise will use the provided iOS Signing information to sign the iOS app.
 
 After these changes, your workflow should look like this (if you target both operating systems):
 
-{{< figure src="/attachments/refguide/mobile/distributing-mobile-apps/building-native-apps/bitrise/select-repository.png" alt="Completed workflow" width="350" class="no-border" >}}
+{{< figure src="/attachments/refguide/mobile/distributing-mobile-apps/building-native-apps/bitrise/workflow.png" alt="Completed workflow" width="350" class="no-border" >}}
 
 ## Build Your App
 
@@ -140,3 +141,7 @@ To set up automatic builds after running **Build Native App**, follow these step
 1. Select the **deploy** workflow and confirm.
 
 Now, every time some runs **Build Native App** to update the application bundle, a new build will be triggered in Bitrise.
+
+## Additional Considerations
+
+Our MVP Marcel Groeneweg has written a blog post about optimizing Mendix native mobile builds with Bitrise. Check it out on [Medium](https://marcel-groeneweg.medium.com/mendix-native-builds-with-bitrise-6ce56f0bb8fc) (Mendix cannot take responsibility for third-party recommendations).