I am brand new to the Web Gateway product. I'm trying to alter the default block page so that it has a link that will email our group and include as much info in the email, automatically, as possible. With my prior product, I was able to do this using wildcards. I cannot for the life of me figure out how to plug in the wildcard into the body of the email successfully with MWG.
Currently, here's the modified line I have (this is Default Schema, en, html, default by the way).
<td class='helpDeskData' background='$<propertyInstance useMostRecentConfiguration="false" propertyId="com.scur.engine.system.proxy.enduserurl"/>$/files/default/img/bg_navbar.jpg'>
If you believe you have received this message in error, click <a href="mailto:firstname.lastname@example.org?subject=Webpage Blocked by Web Security Gateway&body=This website was blocked by Web Security Gateway ">HERE</a> to send a change request.
This works correctly.
If I attempt to add any wildcards (Resource Reference?) I am not successful. If I add URLBlocked.html or URLBlocked.txt, the email does not work properly.
<a href="email@example.com?subject=Webpage Blocked by Web Security Gateway&body=This website was blocked by Web Security Gateway $<propertyInstance useMostRecentConfiguration="false" propertyId="com.scur.engine.system.proxy.enduserurl"/>$/files/default/en/URLBlocked.html ">HERE</a> to send a change request.
The line above actually says $Proxy.EndUserURL$/files...
If I do that, I get this in the body of the email:
This website was blocked by Web Security Gateway /mwg-internal/de5fs23hu73ds/files/default/en/URLBlocked.html
My users are extremely used to being able to just click a button to send the email, and my team is used to getting all the pertinent information in the email without having to dig through logs, etc.
Can this be done?
You should $URL$ within the body=, not $Proxy.EndUserURL$/files...
That method is one way to do it, but you can also setup a set of rules and pages that let MWG do all the work instead of relying on a local mail client to send the mail.
You can setup a way to click on a link:
Then have a form come up to enter comments:
Then submit them back to the MWG and have it send the email:
I need to polish up some rules that a couple of have worked on, but if you're interested I can post.
Oh yea, that's very nice!
I'd love to have those rules. Right now I'm lost at how to do anything more than simple stuff, and training isn't until May.
Ok, unzip this read the readme.txt.
It's probably not self-explanatory, but let me know if you need some assist.
Just make sure you go through the configurationEmail notification settings and put in your own SMTP server information,
And go into the events on the Send Email rule and set the correct email address:
|Enabled||SiteReviewend Email Notification|
1: URL.Path equals "/mwg-internal/sitereview"
2: AND URL.HasParameter("submit") equals true
|Continue||Email.Send("HELPDESK@COMPANY.COM","Site Review Request",String.ReplaceAll(User-Defined.SiteReviewBody,"+"," "))<SiteReviewSMTPServer>||ToDo: Make sure the SMTP configuration is set to your Email server, Make sure the Email Recipient is set properly.|
Then edit the URL Blocked page and paste in the content in the zip for that.
And create 2 other block pages called SiteReviewRequest and SiteReviewSubmitted and paste in the content from the zip into their respective locations.
I've tried to get these working to no avail. I can get the block page to display, but the links don't work to send the request. Keep in mind, I am brand new to this product, so anything I have to do will have to be detailed. This is the first time I've ever worked in the MWG product.
I think I didn't create the SiteReviewRequest and SiteReviewSubmitted pages correctly.
So you can at least get the SiteReviewRequest page to display?
If so, view source, save, zip and send that to me via Private message. We should be able to see what's going on inside the page.
While Tom's solution will work. The advantage of the SiteReview ruleset is that it is totally web based with the email originating from the web gateway itself. This means that you aren't dependent on an email client being present or available on the system with the browser. Were you able to get the ruleset to work? From your comments above, I suspect that the block pages are not correct. You need to create two new block pages and their names need to match exactly. The template for the pages can be your default template so that they maintain the same "look and feel" of your other block pages. Positioning of the ruleset in your policy can also be a factor. The ruleset works via redirects/hyperlinks that are directed to and processed by the web gateway itself.