FAQ/Implementing-Scheduler-Security.md
... ...
@@ -4,6 +4,8 @@
4 4
5 5
By default, the Izenda report scheduler queries the reporting site's response server (rs.aspx) page. Due to the response server calling the InitializeReporting method, this will result in any requests sent from the scheduler to run through the normal program flow, including any security measures to require users to login. Since the scheduler cannot interact with the webpage and click a button to securely login normally, it can be somewhat of a challenge to ensure that the scheduler has access to the site. For this reason, other security measures are required to ensure a secure report scheduler experience.
6 6
7
+##The scheduler executable
8
+
7 9
There are two optional parameters that are available to the scheduler program shipped with the default starter kit. These optional parameters are:
8 10
9 11
* izu
... ...
@@ -17,6 +19,8 @@ Running that command will send the following request to your reporting site:
17 19
18 20
`http://[myreportingsite]/rs.aspx?run_scheduled_reports=[interval]&izUser=[username]&izPassword=[password]`
19 21
22
+##The reporting site
23
+
20 24
The values for izUser and izPassword can then be handled in your InitializeReporting method accordingly, and AdHocSettings.CurrentUserName should be set to the value of [username].
21 25
22 26
Figure 1: The scheduler request and response model
... ...
@@ -27,6 +31,8 @@ As demonstrated in the above graphic, custom code is required to handle the valu
27 31
28 32
Note: The logic for checking izUser and izPassword from the request MUST precede the assignment of AdHocSettings.AdHocConfig if AdHocSettings.RequireLogin is set before AdHocSettings.AdHocConfig, or else the application will redirect to the login page before the logic for checking izUser and izPassword is hit.
29 33
34
+##Custom code
35
+
30 36
An example of the logic used to validate izUser and izPassword might look something like the sample below:
31 37
32 38
```csharp