Basic Authentication using UrlConnection to WebApp

I have a remote windows app(built with Xojo) that sends a request to My WebApp using UrlConnection and Basic Authentiction. My webapp receives the request in HandleUrl. In the Webapp I can get the username and password and use that to validate against my database. My problem is that on the remote app I always receives status 401 in the content received event. It appears that the Basic Authentication always makes a return trip to the remote app, the first trip always returns 401. I need to be able to know that the validation was good in the remote app, but that is in the second response. How do I get the content received of the second response? I got this code off the the forum and modified it a little bet. I don’t want to use a plugin for this simple validation.

case "basicAuth"
  
  var result as Boolean
  var authHeader, items(), auth, username, password as string
 ' var i as integer
  result = false
  
  authheader = request.Header("Authorization")
  
  if authHeader <> "" then
    items = authHeader.Split(" ")
    for i = items.Ubound downto 0
      if items(i) = "" then
        items.Remove(i)
      end if
    next
    
    if items.Ubound = 1 and items(0) = "Basic" then
      auth = DecodeBase64(items(1))
      username = auth.NthField(":", 1)
      password = auth.NthField(":", 2)
      
      response.Status = 200
      result = true
    end if
    
  else
    Response.Header("WWW-Authenticate") = "Basic realm=""MyRealm"""
    response.Status = 401
    result = true
  end if
  return result

I think it might be a bug in URLConnection. Try the workaround from this similar problem: Unable to access a password protected page

If the original request did not contain valid credentials then the server will respond with 401.The client should prompt the user for their credentials (e.g. in the AuthenticationRequested event) and repeat the request. URLConnection appears to be doing this part correctly, however the error result of the original request is persisting and we never see the second request’s success.

The workaround linked above sets the credentials on the original request.

Thanks Andrew, The answer in the link was exactly what I was looking for. It works like I need it to now.
:sunglasses: