Use login form while prepping

[esfalsa]

Fixes #19

This PR uses the login/switching form built into the NationStates site while prepping, instead of sending passwords as search parameters.

[roavin]

That's one possible way to tackle #19.

The code looks fine, and I haven't tested yet. However, the approach is mildly slower due to not being able to use the templated pages anymore, so I'm not sure if this is the way we'd want to do this. @paulhaku , what do you think?

[esfalsa]

I'll briefly note, for the sake of context, that in addition to the page templating aspect, this is also slower because because the login form sends the user to their nation page (as opposed to using GET parameters to log in while navigating directly to the WA page).

[paulhaku]

I thought of a silly alternative.

It turns out that you can set the login target to any page of a login form with its target attribute; it doesn't need to be pointed at /.

Therefore, since logging in doesn't require a localid or chk, you could create the form manually from any page, even on no-template pages.

In theory, this should make the end result identical to the current prep setup but without using GET parameters. I have yet to test this out, though.

Regarding this PR, I tested it out very briefly and it works. I don't think there'd be a speed difference that'd bother anyone.

[esfalsa]

That should work, yeah, and would probably be a bit faster. Tool-crafted requests were a bit outside of the scope I'd had in mind for a keybinding tool, but I suppose it's not that much additional complexity to require an user agent?

[roavin]

Nah; the UA would ideally just link to the github page too.

[paulhaku]

That should work, yeah, and would probably be a bit faster. Tool-crafted requests were a bit outside of the scope I'd had in mind for a keybinding tool, but I suppose it's not that much additional complexity to require an user agent?

Admittedly, it crossed my mind that creating forms is considered a "tool-crafted request". I'm not so sure about this now, but you already put in the work.

[esfalsa]

I'm not so sure about this now, but you already put in the work.

I'm fine with either approach, considering at least one of these PRs isn't going to get merged either way 😛 — I figure both of you are probably in a better position to opine on what should and shouldn't be considered within the scope of Gauntlet and I'm ultimately fine with going along with that.

[roavin]

This PR is now probably obsolete due to #23, right?

[esfalsa]

If we're fine with moving into tool-crafted requests, then yes. Actually, I was holding off on merging because I was curious as to your thoughts about that?