home | list info | list archive | date index | thread index

Re: My Account for Individuals (CRA)

> On 2020-12-11 3:15 p.m., Edward Hong wrote:
> > The fact that you are able to login via TD using your Windows browser
> > client indicates to me that the issue is upstream to your lubuntu client
> > browser. Despite deleting cookies, there is something else amiss.

That might have worked years ago, but not today. Browsers have more APIs
in them these days for persistence: WebQL (now dead), IndexDB,
LocalStorage, SessionStorage, etc. It's also not the simple foreground
page plus single-threaded JS experience anymore: background pages,
service workers, etc.

Also, I haven't found private browsing mode in either Firefox or Chrome
to be reliable ‘from scratch’ browsing emulation. I've had to hackily
poor man sandbox Chrome a few times, though it was usually do to HSTS
which you should never tamper with, not due to other features (like
clearing input/autocompletion caches).

    chromiumi() {
        local tmpdir="$(mktemp -d)"
        sudo mount -t tmpfs \
                   -o mode=0700,uid="$(id -u)",gid="$(id -g)" \
                   "$(basename "$tmpdir")" "$tmpdir"
        mkdir "$tmpdir"/cache
        mkdir "$tmpdir"/config
        mkdir "$tmpdir"/downloads
        echo "$tmpdir"
        sudo \
            unshare --mount \
                    --ipc \
                -- \
                sudo tmpdir="$tmpdir" \
                     -u "$(id -un)" \
                     -g "$(id -gn)" \
                     sh <<- EOF
                    sudo mount --make-private "$tmpdir"
                    sudo mount -o bind "$tmpdir"/config ~/.config/chromium
                    sudo mount -o bind "$tmpdir"/cache ~/.cache/chromium
                    sudo mount -o bind '$tmpdir'/downloads ~/Downloads
                    sudo -k
                    exec chromium "$@"
    EOF
        sudo umount "$tmpdir"
        rmdir "$tmpdir"
    }

Please explore the web inspector's various features. It'll show you a
few things you didn't know about your browser that weren't the case 10+
years ago.

On Fri 2020-12-11 15:26:33 -0500, James wrote:
> > Try installing a different client browser (hopefully there are others
> > available to you), and see if the issue clears itself up.

That doesn't prove anything if you still have extensions from a previous
installation had you installed it prior, or if you have certain distro
packages that cover the browser you're about to install, either of which
is a realistic and possible scenario.

To start from a real clean slate, you need to either sandbox and make
sure no non-default settings are turned on or extensions and plugins
installed, that your network doesn't have policy (e.g., DNS filtering,
IP filtering, HTTP proxying if any) that only applied to the working box
either (e.g., because they were configured differently, which, yes,
happens fairly often in hybrid environments).

> I fixed it.  Don't know why they need it but I disabled AdBlocker.
> Canada.ca is using googleads and youtube (thanks to Alex for
> Ctrl-Shift-I/Network tab).

That's really odd. Googleads and YouTube should never block
authentication or the basic functionality of the site. Perhaps its lists
are overly restrictive? I'm not familiar with AdBlock *implementations*,
etc. though.

If you want more help, provide the list of all request methods/paths
(without query strings, in case of sites that thought it was a good idea
to have credentials there) and their response codes, for the working
case (AdBlock disabled) and the broken case (AdBlock enabled), plus
console logs for each, scrubbed of sensitive data if any.

Cheers,

Alex Pilon

To unsubscribe send a blank message to linux+unsubscribe [ at ] linux-ottawa [ dot ] org
To get help send a blank message to linux+help [ at ] linux-ottawa [ dot ] org
To visit the archives: https://lists.linux-ottawa.org