Fix OAuth authorization via web interface

[michaelrsweet]

The current web interface OAuth support uses the normal authorization flow, but that only allows for a single authorization at a time (auth codes cached by UID). I think we should just support the device authorization flow (QR code and link) which will better work...

[abubakarsabir924-cell]

Hi @michaelrsweet Sir, I'm interested in helping with this transition to the device authorization flow. I see it's currently assigned to you is there a specific part of the implementation I could assist with or take over to help move this toward the v2.5 milestone?

[michaelrsweet]

@abubakarsabir924-cell I appreciate the offer, but unless you have a lot of experience coding OAuth I'm not sure this would be the best task for you to tackle.

Issue #176 has been sitting unfixed for a while and it would be good to get a fresh set of eyes on it to determine why printers aren't showing up.

Issue #1275 involves the docker file used to package up CUPS in a docker image and my limited docker skills are holding things up there as well.

Finally, issue #1304 involves another area in the authorization code; I haven't had a chance to do any deep investigation but it is another important bug fix we want to have for 2.5...

[abubakarsabir924-cell]

@michaelrsweet Sir, Thanks for the guidance,I really appreciate you sharing these specific issues with me.
Coming from an arts background, I’ve developed a natural curiosity to tackle problems from different perspectives, and I'm always eager to dive into new challenges. I will investigate all three issues (#176, #1275, and #1304) step-by-step and will do my best to provide solid fixes for them.
I'll start with the investigation and keep you updated on my progress. Looking forward to making more impactful contributions sir!

[tillkamppeter]

@abubakarsabir924-cell also #1531 is worth a look. It annoys me already for some time.

[abubakarsabir924-cell]

@tillkamppeter Sir, Thanks for pointing this out, I'll make Issue #1531 my top priority..

[abubakarsabir924-cell]

Hi @tillkamppeter and @michaelrsweet Sir's,

I've been doing deep investigation on issue #1531 for the past 3 days and I think I've found both the root cause and a viable fix.
Root Cause:
In cups_enum_dests(), the permanent cupsd queues are stored in a local dests variable but are never stored in _cups_dnssd_data_t. So when DNS-SD discovery happens, there is no local queue data available to compare against discovered printers.
Proposed Fix:
Instead of UUID comparison (which has async timing issues since UUID arrives later in TXT record parsing), I propose comparing the rp field from the DNS-SD TXT record against local permanent queue names in cups_dest_query_cb().
The rp value like printers/envy can be matched against local queue name envy — if they match, the discovered printer is already served locally and should be suppressed.
This avoids the timing issues of UUID approach since rp is available directly in the TXT record at parse time.
Would you give me a go-ahead on this approach, or suggest a better alternative before I submit a PR?

[tillkamppeter]

@abubakarsabir924-cell Thanks for the work on issue #1531 but could you please post your findings (please also copy and paste your comment above) on #1531. Thanks. This issue, #1556 has nothing to do with #1531.