Ok, so I know how to pass the username and password using the AuthenticationRequested event, but how do I know whether it was successful?
Seems if it fails, it sits in a loop, trying forever.
Also, what does returning “False” instead of “True” do?
returning false isnt documented at all is it ?
returning true says “yeah we filled in credentials so try those”
returning false is akin to “authentication failed” or something I think
looks like it wasnt documented when it was Xojo.Net.HTTPSocket either 
Yeah, I did some searching before I asked, and there’s nothing I can find.
Why it even needs to return anything is a mystery, but it would be useful to return a true/false if there were a way to tell if the login were successful within that event…
Thinking about this further, I would think that a failed login should produce an http error, but it doesn’t. The URLConnection just sits in a loop trying over and over. I’m struggling to think what good this event is and how one authenticates where a user could enter a username/password in software and have it try and produce a pass/fail…
It doesn’t fire the Error OR ContentReceived Event either.
Using an event like this is one way to set up a “chain of responsibility” pattern
Basically Xojo’s code can’t decide what to do for you in all cases so this is how they ask you what to do
In their code they probably have something like
dim realm As String
dim name As String
dim password As String
if raiseEvent AuthenticationRequested(realm, name, password) = true then
// respond with the realm user name & password
else
// give up and do not try anything further
end if
however it seems that returning false doesnt “give up” which maybe it should or it should raise some other event like Error or maybe a new one like AuthenticationFailed
Without reading their sources (which I dont have) I cant say what it really IS trying to do so … 
EDIT : Have you tried this with the Xojo.Net.HTTPSocket ?
This is where URLConnection originated from and maybe this one works but URLConnection doesnt indicating some other change when it got transitioned over ?
Its a shot in the dark but may be worth it
1 Like
No difference (once all the conversions were done).
I guess the only workaround would be to set a flag in the Send method, then reset it in the AR event.
If it’s reset then return false.
If you return true from the AR event, and the username/password is incorrect, it tries forever.
If you return false from the AR event, regardless of the user/pass, you’ll get 401 for HTTPStatus, and the content will be whatever page your server has for failed authentication.
e.g.
Unauthorized
This server could not verify that you are authorized to access the document requested. Either you supplied the wrong credentials (e.g., bad password), or your browser doesn’t understand how to supply the credentials required.
I think that is a standard sequence. Servers are basically designed to talk to Browsers.
Logging in manually from a browser window, the server would keep presenting the User/Password request until you got it right or you pressed Esc to abort. If you aborted, you would get the error page.
When you automate the process, if the id/password is wrong, your program needs to figure out why and try something else.
So what you’re saying is that the browser (and the URLConnection) is unaware of whether the login was successful and if the login page is coming up again?
Bummer
This makes sense
As does returning true since that says “try this username password”
Indeed
The URLConnection is more or less “the protocol handler” and the state is something your app needs to handle
You could be trying to log into something completely custom and the URLConnection would never know how that login sequence worked or not
It just transmits & receives the data
No. You don’t get new content or status. ContentReceived and Error events are not called if you return True. In fact, you cannot do another “Send” until it succeeds or you return False.
Here’s my solution:
Create a custom URLConnection and add a boolean property like AuthCheck.
Override the Send Method and add:
AuthCheck = True
// Calling the overridden superclass method.
Super.Send(method, URL, timeout)
Change the super of your URLConnection instance to this CustomURLConnection.
Then in your instance URLConnection, add to the AuthenticationRequested event:
name = "name"
password = "password"
If Me.AuthCheck Then
Me.AuthCheck = False
Return True
End If
Return False
And it all works hunky-dory.
The browser is aware that the login did not succeed. The dialog/protocol assumes that an operator sees the request. It will keep asking for the id/password until the server responds successful. The interaction was designed around an operator ‘surfing’ in person. Automation (spiders/bots) are an afterthought and need to simulate what an operator would do.
Right. So far my “mod” seems to be working.
I might see if I can create a generic custom URLConnection that handles this internally if I get ambitious.
that definitely seems like a bug of some sort