You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: content/en/docs/appstore/modules/document-generation.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -87,7 +87,7 @@ If you have installed Chrome in a custom location, configure the path to the Chr
87
87
88
88
##### 3.1.2 Chromium
89
89
90
-
If you use Chromium, only use stable releases. The currently supported stable release is [104.0.5109.0](https://storage.googleapis.com/chromium-browser-snapshots/index.html?prefix=Win_x64/1011831).
90
+
If you use Chromium, only use stable releases. The currently supported stable release is [104.0.5109.0](https://storage.googleapis.com/chromium-browser-snapshots/index.html?prefix=Win_x64/1011831/).
91
91
92
92
Download the *chrome-win.zip* package and extract the archive to a location of your choosing.
Copy file name to clipboardExpand all lines: content/en/docs/howto7/general/dev-best-practices.md
+26Lines changed: 26 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -310,6 +310,32 @@ Use microflow [error handling](/howto7/logic-business-rules/set-up-error-handlin
310
310
311
311
Complex processes and important business logic (like workflow processing or validations) must include debug and trace [logging](/refguide7/logging/). Logging actions must write the current state and progress of the process and must include a request ID or other identifying information. The log node should be the name of the module. This will greatly assist error analysis.
312
312
313
+
#### 4.2.6 Validating Inputs in Microflows
314
+
315
+
When microflows are invoked from the client side, it is important to validate the inputs. By having validations, you prevent incorrect, inappropriate, or potentially harmful data from being used in your microflows. This protects your application against security vulnerabilities. The following presents the best practices regarding the integrity and validation of inputs in your microflows.
316
+
317
+
##### 4.2.6.1 Implementing Validation Checks
318
+
319
+
Adding validation checks is vital for ensuring that input data conforms to the expected data type, format, range, or other application-specific constraints. For instance, if a numeric input is expected within a defined range, validation checks should confirm that the input is indeed numeric and falls within the specified range.
320
+
321
+
##### 4.2.6.2 Managing Unexpected Values
322
+
323
+
When building microflows, it is important to account for the potential occurrence of unexpected values. These could be empty values, or values outside the expected range or format. It is also important to ensure that read-only attributes only contain expected values.
324
+
325
+
{{% alert color="warning" %}}
326
+
We strongly recommend adding validation checks to all microflows inputs, including read-only attributes.
327
+
328
+
We also recommend avoiding storing intermediary values in attributes (such as, *TotalPrice*). Instead, calculate these values when needed to ensure you have the correct values.
329
+
{{% /alert %}}
330
+
331
+
Microflows should incorporate mechanisms to detect unexpected values and respond suitably – this might involve returning an error message to the end-user or executing a fallback operation.
332
+
333
+
##### 4.2.6.3 Updating Validation Logic Regularly
334
+
335
+
As the application evolves, the validation logic within microflows should be updated accordingly to reflect changes in business logic or data models. This regular review and update of validation checks ensures that microflows remain secure and function correctly over time.
336
+
337
+
By prioritizing the validation of inputs in microflows, you not only enhance the security of your application, but also ensure a more predictable and stable user experience. This practice underscores the development of reliable and robust applications.
338
+
313
339
### 4.3 Warnings and Modeler Feedback
314
340
315
341
No warnings should be visible in the Modeler, unless explicitly documented with a reason. Warnings can indicate many issues, including maintainability and security risks, which must be resolved.
Copy file name to clipboardExpand all lines: content/en/docs/howto8/general/dev-best-practices.md
+26Lines changed: 26 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -329,6 +329,32 @@ Use microflow [error handling](/howto8/logic-business-rules/set-up-error-handlin
329
329
330
330
Complex processes and important business logic (like workflow processing or validations) must include debug and trace [logging](/refguide8/logging/). Logging actions must write the current state and progress of the process and must include a request ID or other identifying information. The log node should be the name of the module. This will greatly assist error analysis.
331
331
332
+
#### 4.2.6 Validating Inputs in Microflows
333
+
334
+
When microflows are invoked from the client side, it is important to validate the inputs. By having validations, you prevent incorrect, inappropriate, or potentially harmful data from being used in your microflows. This protects your application against security vulnerabilities. The following presents the best practices regarding the integrity and validation of inputs in your microflows.
335
+
336
+
##### 4.2.6.1 Implementing Validation Checks
337
+
338
+
Adding validation checks is vital for ensuring that input data conforms to the expected data type, format, range, or other application-specific constraints. For instance, if a numeric input is expected within a defined range, validation checks should confirm that the input is indeed numeric and falls within the specified range.
339
+
340
+
##### 4.2.6.2 Managing Unexpected Values
341
+
342
+
When building microflows, it is important to account for the potential occurrence of unexpected values. These could be empty values, or values outside the expected range or format. It is also important to ensure that read-only attributes only contain expected values.
343
+
344
+
{{% alert color="warning" %}}
345
+
We strongly recommend adding validation checks to all microflows inputs, including read-only attributes.
346
+
347
+
We also recommend avoiding storing intermediary values in attributes (such as, *TotalPrice*). Instead, calculate these values when needed to ensure you have the correct values.
348
+
{{% /alert %}}
349
+
350
+
Microflows should incorporate mechanisms to detect unexpected values and respond suitably – this might involve returning an error message to the end-user or executing a fallback operation.
351
+
352
+
##### 4.2.6.3 Updating Validation Logic Regularly
353
+
354
+
As the application evolves, the validation logic within microflows should be updated accordingly to reflect changes in business logic or data models. This regular review and update of validation checks ensures that microflows remain secure and function correctly over time.
355
+
356
+
By prioritizing the validation of inputs in microflows, you not only enhance the security of your application, but also ensure a more predictable and stable user experience. This practice underscores the development of reliable and robust applications.
357
+
332
358
### 4.3 Warnings and Studio Pro Feedback
333
359
334
360
No warnings should be visible in Studio Pro, unless explicitly documented with a reason. Warnings can indicate many issues, including maintainability and security risks, which must be resolved.
5. Publish both microflows as web service operation of the **CustomerWebservice** as described in chapter 4 of the how-to [Exposing a web service](/howto8/integration/expose-a-web-service/).
51
53
@@ -55,39 +57,39 @@ In this chapter you will create a new SOAP project.
@@ -142,15 +144,15 @@ In this chapter you will build a testsuite. A testsuite contains one or more tes
142
144
Assertions are used to validate the message received by a TestStep during execution, usually by comparing parts of the message (or the entire message) to some expected value. Inthis chapter you will create an assertion that validates the number of customers.
5.Enter*count(//Customer)* in the XPath Expression field.
152
154
6.In step 1.4 of the previous how-to you have added some data. Enter the number of created customers in the **ExpectedResult** field. Inthis example four customers were created.
Copy file name to clipboardExpand all lines: content/en/docs/howto8/mobile/native-mobile/getting-started-with-native-mobile.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -25,7 +25,7 @@ Before starting this how-to, make sure you have completed the following prerequi
25
25
* For information on device requirements, see [System Requirements](/refguide8/system-requirements/)
26
26
* If you wish to use an emulator for Android mobile testing, install a product such as [Bluestacks](https://www.bluestacks.com/nl/index.html) or [Genymotion](https://www.genymotion.com/) (your emulator must have Google Play services supported)
27
27
28
-
## 3 Creating a New App Based on the Quickstart App {#quickstartapp}
28
+
## 3 Creating a New App Based on the Quickstarter App {#quickstartapp}
29
29
30
30
For details on making a Mendix app using the Blank Native Mobile App template, download the Make It Native 8 app on either the [Google Play store](https://play.google.com/store/apps/details?id=com.mendix.developerapp) or the [Apple App Store](https://apps.apple.com/us/app/make-it-native/id1334081181). This app template includes the latest version of Atlas UI, as well as the [Native Mobile Resources](/appstore/modules/native-mobile-resources/) module containing widgets and nanoflow actions for native mobile apps. For more information on building native mobile apps, see the [Build a Native Mobile Inspection App](https://academy.mendix.com/link/path/66) learning path (you must be signed in to the Mendix Platform to see this learning path). Using the Make It Native app to view the changes to your Mendix app, see the sections below.
Copy file name to clipboardExpand all lines: content/en/docs/howto8/mobile/native-mobile/native-styling/how-to-use-native-styling.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -14,10 +14,10 @@ With Mendix 8, you have the capacity to alter design properties with Mendix Stud
14
14
## 2 Prerequisites
15
15
16
16
* Install an integrated development environment (IDE) of your choice (Mendix recommends [Microsoft Visual Studio Code](https://code.visualstudio.com/))
17
-
* Create a Mendix app based on the Blank Native Mobile App template by following the [Creating a New App Based on the Quickstart App](/howto8/mobile/getting-started-with-native-mobile/#quickstartapp) section of *Get Started with Native Mobile*
17
+
* Create a Mendix app based on the Blank Native Mobile App template by following the [Creating a New App Based on the Quickstarter App](/howto8/mobile/getting-started-with-native-mobile/#quickstartapp) section of *Get Started with Native Mobile*
18
18
* Download the Make It Native 8 app on your mobile device via either the [Google Play](https://play.google.com/store/apps/details?id=com.mendix.developerapp) store or the [Apple App Store](https://apps.apple.com/us/app/make-it-native/id1334081181) so you can text your app and see your styling changes
19
19
20
-
### 3 Customizing the Quickstart App
20
+
### 3 Customizing the Quickstarter App
21
21
22
22
The [Blank Native Mobile App](https://marketplace.mendix.com/link/component/109511/) is styled using an Atlas UI resources package. This package consists of:
0 commit comments