[Edbrowse-dev] A possible login issue on gkg.net

[Edbrowse-dev] A possible login issue on gkg.net

[Chuck Hallenbeck]

Hi all,

Last evening I created an account at gkg.net, a domain registrar,
which seemed successful. They sent me email, I followed the link it
contained, they acknowledged that I was me, and even called me Chuck
on their first page. Then I turned in for the night.

This morning I tried logging in to continue what I wanted to do,
but my login failed with "403 forbidden."

I tried repeatedly, being certain to enter my ID and PWD correctly. but
no dice.  

Next I captured a log of the login attempt with db4 activated and
timers turned off, and am hoping somebody with more savvy than I will
take a look at it, perhaps spotting something that will implicate
edbrowse or find it innocent.

It's on a VPS which does not yet have a domain name, and is called
gkg-net-403

It can be retrieved here:

wget http://45.33.14.163/gkg-net-403

Thanks for any light you can shed on this.

Chuck

-- 
Liberty without Equality is a Jungle. Equality without Liberty is a Jail.

[Edbrowse-dev] A possible login issue on gkg.net

[Karl Dahlke]

Did you look at the page, despite the 403 error?
There's another login form, and it also says we need to activate cookies,
which suggests perhaps a problem with edbrowse and cookies,
and it also says you have to pass a captcha to log in, which suggests you are out of luck.
IDK

Karl Dahlke

Re: [Edbrowse-dev] A possible login issue on gkg.net

[Kevin Carhart]

Just regarding the cookies message, I find that this sometimes displays 
even though it isn't true.  There's a lot of these situations where mutually 
exclusive statements are both in the HTML, and one is intended to be 
removed by JS.  It could say "You are logged in," "You are logged out."

I think the login screen of amazon says "you must enable 
cookies" at the top, but we certainly did have cookies working all 
throughout the recent amazon adventure.  Beware believing all assertions 
that are sitting in html.  Sorry this isn't specific help on gkg - I will 
try to pull this up specifically in a little while.



On Tue, 6 Mar 2018, Karl Dahlke wrote:

> Did you look at the page, despite the 403 error?
> There's another login form, and it also says we need to activate cookies,
> which suggests perhaps a problem with edbrowse and cookies,
> and it also says you have to pass a captcha to log in, which suggests you are out of luck.
> IDK
>
> Karl Dahlke
> _______________________________________________
> Edbrowse-dev mailing list
> Edbrowse-dev@lists.the-brannons.com
> http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev
>

---

[Edbrowse-dev] A possible login issue on gkg.net

[Karl Dahlke]

[-- Attachment #1: Type: text/plain, Size: 1565 bytes --]

The thing we have to remember, I have to remember, is when the second page issues a 403 error, there's no point in looking at the second page, neither its html nor its js nor its css.
The error occurred before we got any of that data.
It's all about the first page, and the http exchange to fetch the second page, which looks right to me, according to db4.
I did something I haven't done in years, downloaded lynx and ran it.
With no screen readers etc, this is the only other browser I can run.
I pulled up the home page, put in a fake login and password, went to the next page, and got the same 403.
So lynx doesn't handle it either, and lynx probably does cookies properly, and certainly sends the post request properly, so that rules out a couple of things.

The next step, which I am not able to do, is to run this in chrome or firefox and sniff the packets as they go by,
and see exactly what http headers it is sending to gkg to get the second page.
If you have a proxy server with monitor perhaps you could use that instead of a packet sniffer.
That might be worthwhile if we were serious about debugging edbrowse in the ongoing future,
so we could compare and contrast internet traffic.
Logically, if we send exactly the same http headers as firefox, it will work.
Yes, I tried changing the user agent, that didn't help.

By coincidence, tsp ran into a 403 error, and we fixed it by fixing referer, which is part of the http headers, and was not being sent properly.
I was hoping that was it here, but referer looks right.

Karl Dahlke