I have a login page but the browser doesn't offer to remember the username/password. It's probably something to do with the fact that my login mechanism is over AJAX and not a form submission.

Is it possible to do with an AJAX login?

squiffy wrote:

> I have a login page but the browser doesn't offer to remember the
> username/password. It's probably something to do with the fact that
> my login mechanism is over AJAX and not a form submission.
>
> Is it possible to do with an AJAX login?

I have this on my web shop. After a while, Chrome did start
auto-filling, but not sure how. But I just used the LocalStorage to
save the details, with a checkbox to allow people to turn that off.

--

Matthew Jones

"Matthew Jones" wrote:
>> But I just used the LocalStorage to
>> save the details....

This is all new territory for me, but isn't that rather insecure? Local storage is not encrypted, and manually encrypting would be no more secure as the encryption method will be in code in the browser.

Unless I've misunderstood, when the browser saves the password data it encrypts it from within the browser. Not unbreakable, I agree, but probably safer than using JS available storage.

Forget it.
I can see no reason not to use <form> and submit it as normal in my app, so I'll do that instead. That triggers the browser save box as expected.

Is there any way I can detect the http code in the TBrowser control I must feed the form result into?
I can obviously read and parse the document text, but I would prefer, if possible, to act upon the code.

squiffy wrote:

> "Matthew Jones" wrote:
> >> But I just used the LocalStorage to
> >> save the details....
>
> This is all new territory for me, but isn't that rather insecure?

Yes - it isn't ideal. I do a basic encryption, but fundamentaly I
choose to trust that the user will be aware that remembering the
password means that their machine is storing it somewhere. The
"remember my details" checkbox is coded so that unchecking it deletes
the relevant local storage immediately. Just as with the Chrome
password reveal, which used to be a click away for anyone on the
computer, it comes down to access. ALthough F12 revealed the details,
it isn't "obvious" and there in plain text for someone to copy down.

--

Matthew Jones

<< Is there any way I can detect the http code in the TBrowser control I must feed the form result into?
I can obviously read and parse the document text, but I would prefer, if possible, to act upon the code. >>

What do you mean by "code" ?  Do you mean the actual DOM elements ?  If so, then yes, you can access them, but it has to be from a TBrowser descendant class because the relevant properties are protected.  What you want is this:

TBrowser.WebElement -> is a TFrameElement, which contains a DOMElement property that contains the THTMLElement document element, which is actually a THTMLFrameElement.  All of the DOM element classes are declared in external interfaces in the WebDOM unit.

You can see how all of this works in the WebUI unit for the TFrameElement:

function TFrameElement.GetFrameDocument: THTMLDocument;
begin
  if Assigned(DOMElement) then
     Result:=THTMLDocument(THTMLFrameElement(DOMElement).contentDocument)
  else
     Result:=nil;
end;

function TFrameElement.GetDocumentText: String;
begin
  if Loaded then
     Result:=THTMLElement(GetFrameDocument.documentElement).innerHTML
  else
     Result:='';
end;

It's a lot of casting about, but that's how the DOM classes work.

Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:
>> What do you mean by "code" ?  

I meant something far simpler - the HTTP status code (200, 401, 500, etc.) resulting from the form POST.
I can't see any way to access that in the TBrowser component; I can only set and read the DocumentText. Not a major thing for the log in page. Anything other than token= can be considered a failure.

<< I meant something far simpler - the HTTP status code (200, 401, 500, etc.) resulting from the form POST.
I can't see any way to access that in the TBrowser component; I can only set and read the DocumentText. Not a major thing for the log in page. Anything other than token= can be considered a failure. >>

Ahh, yes, in that case you'll need to have the server return that information as content in the response.  That's the only way to get at it in order to parse it, etc.

Tim Young
Elevate Software
www.elevatesoft.com