Create iCalendar entry with agent

HCL Domino Domino Forum
1

I have a simple agent I am trying to use to create an iCalendar stream. The agent looks like this:

Sub Initialize

Print "Content-type: text/calendar" & Chr(13) & Chr(10)

Print ""

Print "BEGIN:VCALENDAR" 

Print "VERSION:2.0"

Print "PRODID:-//DTF//Projects//EN"

Print "BEGIN:VEVENT"

Print "UID:20090427T150000Z-12345@blah.blah.au"

Print "SEQUENCE:0"

Print "DTSTART:20090427T150000"

Print "DTEND:20090427T160000"

Print "SUMMARY:Nigel Test"

Print "DESCRIPTION:This is the description"

Print "TRANSP:TRANSPARENT"

Print "END:VEVENT"

Print "END:VCALENDAR"

End Sub

When I hit it in a browser - http://server.domain.com/nigel/test.nsf/ical?OpenAgent

I can save the file as a .ics and import it into notes with no problem.

When I try and add it as a [feed]to the notes client using the same url - I get a feed error which says

net.fortuna.ical4j.Data.ParserException: Error at line 1: Expected [BEGIN], read []

Now, that would make sense if the agent wasn’t rewriting the mime type to text/calendar, but I have checked the HTTP Header and it’s right.

Any ideas?

2

Subject: Try this…

Hi Nigel,

modify your agent like this and look at the server console while it is running:

Sub Initialize

 MsgBox("Agent is running.")



 On Error Goto processError



Print "Content-type: text/calendar" & Chr(13) & Chr(10)

Print ""

Print "BEGIN:VCALENDAR" 

Print "VERSION:2.0"

Print "PRODID:-//DTF//Projects//EN"

Print "BEGIN:VEVENT"

Print "UID:20090427T150000Z-12345@blah.blah.au"

Print "SEQUENCE:0"

Print "DTSTART:20090427T150000"

Print "DTEND:20090427T160000"

Print "SUMMARY:Nigel Test"

Print "DESCRIPTION:This is the description"

Print "TRANSP:TRANSPARENT"

Print "END:VEVENT"

Print "END:VCALENDAR"



 MsgBox("Done.")



 Exit Sub

processError:

 MsgBox("Error " & Err & " in line " & Erl & ": " & Error$)

 Exit Sub

End Sub

This way you can see whether your agent is running (I still suspect that it is not running) or not, or if it running into an error.

Best regards,

Mario Varchmin

e-llennium GmbH

3

Subject: It’s definitely running

And without errors. I get the start and end messages on the console.

4

Subject: This has been fixed in 8.5.2

I did some investigation into this and it turns out it has been SPRed (SPR#TBAY7VZNFX) and fixed in 8.5.2Thanks!

Nate

5

Subject: SPR’d and fixed in the next release.</>

6

Subject: We’re having exact same issue

Nigel,

Nasty problem, in that, as best as we could ascertain, its rare (yours is the only other incident I’ve seen on the internets).

Classic good news/bad news situation: We know exactly whats going on, but we’ve no clue as to the root cause or how to fix it.

Let me tell you what we’ve found so far.

The error message you’re seeing is in fact an authentication challenge (the login form) coming from the server to your Calendar client. Of course it looks nothing like an iCal feed and thus promptly fails.

Of course, your agent doesnt require authentication and ACL isnt an issue.

The reason that form comes up (or, rather, gets sent) we think is because Calendar client sends a basic authentication token/header (we’ve confirmed that by sniffing http traffic) as part of HTTP iCal GET request.

If you were to go to your personal NAB, advanced configuration, you’ll see that for each iCal subscription there exists an Account document, containing all the information required to connect to the feed, including a name and a password, prefilled with the literal values “com.ibm.rcp.navigator.emptyusername” and “com.ibm.rcp.navigator.emptypassword” (to see the password, change field type to “Text” in designer).

These are the name and password used by Notes Calendar to create a basic authentication http header token. We have also confirmed that by sniffing and decoding the actual base64 value of that header.

Removing (blanking out) the password seems to completely suppress basic authentication token, subsequently “fixing” the problem.

Providing a valid username and password into the Account document, also appears to reliably fix the problem.

In SOME instances, and we couldnt so far find any pattern to that, Notes Calendar does NOT submit basic authentication token, and thus this problem isnt observed at all. This seems to be per-iCal-URL specific. Once a URL becomes “cleared” the Calendar no longer sends basic authentication token with it. Using that same URL in another Account document continues to “work” (that is to say, not send BAuth), yes that same URL if used on another workstation might fail.

This seems to suggest some sort of a caching or cookie type situation, but thats a pure speculation at this point, we’re continuing to investigate this angle.

We’ve contacted IBM about this problem, they’re looking into it. Some of this incident they’ve been able to confirm, but not all. Which makes it difficult to get them to escalate the issue.

This is about as far as we’ve been able to get.

Rouslan

7

Subject: Maybe the ACL?

Hi,

have you checked that the agent can be called/used by an anonymous user? If the parser tells you that it reads and not BEGIN, then it probably really reads . It may read an error text (error 500 or 404) or a login form.

Best regards,

Mario Varchmin

e-llennium GmbH

8

Subject: Unfortunately not ACL

Thanks for the response Mario. I have been able to determine that it’s not the ACL (the agent runs properly when called by an anonymous browser), but I appreciate you taking the time to suggest it.