APM Sharepoint authentication
Problem this snippet solves: Updated version to support Webdav with windows explorer after Nicolas's comment.
APM is a great authentication service but it does it only with forms.
The default be...
Published Apr 20, 2016
Version 1.0Stanislas_Piro2
Cumulonimbus
Joined January 04, 2011
Stanislas_Piro2
Cumulonimbus
Joined January 04, 2011
Stanislas_Piro2
Sep 18, 2016Cumulonimbus
Hi Kai,
here are my answers:
- Line 11-13: Make this option a static::variable. : No, if it is static::variable, it won't change when changing Access profile since the irule is reload (static::variable goal is to be set in RULE_INIT).
- Line 15: Unify the syntax within your script to either [HTTP::header MyHeader] or [HTTP::header value MyHeader]. : I agree. I will change it.
- Line 17: Leftover log line? : debug log i forgot to remove
- Line 18: The HTTP::header exists makes much sense. I've updated my own script to include this.
- Line 19: I don't see a reason to use two independent variables for forms and client_less. Using a multivalue would make things easier. You may use 0 for browser, 1 for MSOFBA and 2 for Clientless. In this case you could apply certain script blocks for ==1 ==2 or even >0 : I agree, but I must change it and manage in ACCESS_SESSION_STARTED, time was missing
- Line 20,21: Make sure that each switch script block sets both variables. In this case you don't need set them to 0 at the beginning. It will safe some cycles. I will change to one variable
- Line 51: Remove this line. HTTP::header insert should not throw an error and line 52 will nevertheless insert the cookie for you. Cookie insert,as most of HTTP commands, can throw an error if previous HTTP response command was executed before (another irule or LTM Policy)
- Line 53: Keep in mind that you should reset this variable once a cookie has been issued. Currently it will issues a cookie on consecutive requests. Alternatively set this variable on each request depending on the enumerated client type.
- Line 68: Remove the == 0 and flip the order of the [if]. It may save your some additional cycles.... : OK, I got it from F5 exchange irule
- Line 111: I would make sure that only browser are allowed to issue persistent cookie. I guess there is no reason to inject persistent cookie for non-browser clients.
- Line 112: A SharePoint wouldn't use a cookie name of MRHSession_SP, so you don't need to remove it. : Right
- Line 113-114: Combine this two commands using a HTTP::header insert it will safe some cycles. Also try to issue a HttpOnly header. It will work with Office clients. I agree, I will do it
- Line 135-137: There is no need to random-delay the 401 within ACCESS_POLICY_COMPLETED. Its already auto-random-delayed. The delay would be required only for 401 responses within the HTTP_REQUEST event. I tested it an in clientless mode and the auto random delay was not working on version 12.0, I will try again
- Line 118: There is no need for the [info exists]. The variable is set during CLIENT_ACCEPTED and the not removed. : Right
And Lines 100 - 101: same cookie remove than lines 102 - 103. lines 100 and 101 will be removed.