Ok, Since there were no responses and I ran within the team and tried and tested for over 4 weeks, here is what we did as far as we can rememeber or work out (As much for me as anyone else:)).
1. Forget about integrated 4 on iis 7, we changed and used classic 2.0 - it did not work and we tried ALL the advice.
2. Could not get the geko engine working, even when we followed all the advice, default printer, bin files, .ddl installation etc. (more importantly there are restrictions with the geko engine in regards to css and the ability to use print.css rather than display.css).
3. This will work for a while, and when you think all is well, you wake up its gone wrong again (Cannot activate MSHtml engine. Please refer to documentation for more information), go into iis and:
IN the IIS Application pool, Select the application (abcpdf.net) go to advance setting and Property Load user profile = true; (thank you to a fellow contributor)
4. So far its been working for about 4 weeks
If you are using master pages and linking your css via the master page, you will be told not to use relative links (~/etc/etc), but absolute (../../). It does not work. When you send anything to print via abcpdf.net server side, use a querystring or something to identify the app and swap the .css file on the page init. for example:
Protected Sub Page_Init(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Init
Dim css As New HtmlLink()
If Request.QueryString("PrintID") Is Nothing Then
Else
css.Href = "~/print.css"
css.Attributes("rel") = "stylesheet"
css.Attributes("type") = "text/css"
css.Attributes("media") = "all"
Page.Header.Controls.Add(css)
End If
End Sub
Thats about it.
Your pages will be printed exactly like hitting a page preview in an browser, except where you are using javascript to adjust client side controls (like dev express component), when you can expect more fun!
The original question was about authorisation when using a password protected site and attempting to print pages within this site. ABCPDF will be treated like a new user and you will need to authorise from your code behind or you will end up with prints of your log in page. Our application bans persistent sessions, so we did not and could not follow the advice from abcpdf.net (who are very helpful). We did this which may not be elegant but...
1. When a user clicks a print button create an id (GUID perhaps) within your database (or may be a file you can open and reference),
2. Set up a known user (with minimum rights) and encrypt the credentials in the code behind,
3. Pass the id (encrypted) to a querystring when ABCPDF.NET attempts to open a page eg,
created_URL = url & pagename & "?PrintID=" & printid ' encrypted
theID = thedoc.AddImageUrl(created_URL)
4. In each page, if the id can be found within the database, use the encrypted known user, decrypt and authorise (if it can't redirect the user to an abuse page)
5. Print the page. You will need this page load event in all pages (but you can use the same event for other things). You may need to authorise once, you may need to do this on each page (we created a printhelper.vb to deal with this including the encrypted user credentials)
6. Delete the print id so it cant be used again
No, its not as elegant as it could be. But it all happens server side and is encrypted, and you can use the ID event for other monitoring etc. Oh yes...it works!