We have developed a DSAPI filter for R5. However the behaviour is not good in R6.Problem 1:
A user hits a protected page. The user is prompted for a username and password.
In case the user enters a wrong password the filter specifies authData->authType=kNotAuthentic and return kFilterHandledEvent.
In R5 the user is prompted a second time for a username and password. Then a third time and then some error page is displayed
However in R6 the user is NOT prompted a second time for a username and password. A “page not found” error is displayed in the browser
Problem 2:
R5 behaviour: after three attempts the user get the “invalid user/pwd” screen. The URL in the address bar is still the original URL. The user could refresh the page and gets another three tries
R6 behaviour: the address bar contains the original URL. The user refreshes the page. The DSAPI is called with the old username and password. The user is not prompted for a username and password. The only solution for the user is to close the browser
The problem appears in 601 and 602.
The setting of CheckCacheBeforeDSAPI has no influence
It happens with standard and session based authentication
Subject: R5 DSAPI not working in R6 - same problem here
Same problem here
on kNotAuthentic and kFilterHandledEvent, the Web user is never prompted again.
I downloaded the 6.02 toolkit, noticed some new functions and features related to DSAPI, recompiled my filter using that toolkit - no avail, same result
my server is 6.01
help ?
Edit: same problem in 6.02 CF1 (
Edit2: ran very same dsapi dll (dit not even recompile) on a R5.0.11 Server, and it works as expected!
(with help from the Lotus Support and the Partner Forum)
we are both wrong:
the R5 doc says that after a kNotAuthentic, we should return kFilterNotHandled
but the dsapi3.c sample returns kFilterHandledEvent, and it works well, and since I used that sample to write all my subsequent dsapi filters, the R5 doc fell into oblivion and I was pretty sure returning kFilterHandledEvent was the legal way to do it
then came R6
and kFilterHandledEvent did not work - I rushed to the R6 doc and lo, there, it is writtent that kFilterHandledEvent WAS the way to do it!
big mistery
actually
the R5 doc was right all along
the R5 DSAPI kernel had a “bug” which allowed wrong behaviour (returning kFilterHandledEvent) to work
the R6 DSAPI kernel no longer has that bug
BUT the R6 doc is wrong!
so, return kFilterNotHandled after a kNotAuthentic and you code will work “legally” in both R5 and R6
So in R5 -due to this bug- we could write a DSAPI filter that either:
-authenticates and says the user is not ok, but do not pass on authentication to domino or other dsapi filters
-authenticate and says the user is not ok, but pass to others.
Since this was considered to be a bug, it is no longer possible to do this in R6. Is there a workaround for R6 to recreate this behaviour. Our authentication DSAPI requires a configuration parameter that can be set by the administrator in order to allow/disallow passthrough authentication.
I have exactly the same problem. I used this “bug” in R5 to say user is not ok and do not use domino authentication. On Domino 6 the behavior is different.
To emulate the R5 behavior I will test two scenarios in the future.
If the user is not ok and domino should not attempt its own authentication I do:
overwrite the username and/or password that was given in the request. So dominos own authentication will fail and the login-page will be displayed.
If scenario 1 doesn’t work I will try inter-event communication. That means besides the authUser event i will catch the rewriteURL event. So, if the user is not ok i will return kNotAuthentic and FilterHandledEvent. Before I return this Event I have to store a flag in memory (?) that signals the filter in the rewriteURL event if it should display the login-page or not.
Yes we have constructed this bypass too by replacing the username with “-” so that Domino will not validate the user, after detecting the Domino release – for R5 we still proceed as before.