Improve user/x/openid_sites

Bigger picture http://img.skitch.com/20090309-x68fsx3f1bfk8c7dx87pa696ni.jpg

Here is the patch which implements this style of openid_sites listing and UI.

Attachment	Size
openid_provider_sites_page.patch	4.06 KB

Nice improvement!

Marked http://drupal.org/node/395010 as duplicate.

patch doesn't apply cleanly.

This patch applies cleanly on head. But it seems to reverse the way the checkbox behave. The checkboxes are severly broken: they don't persist and don't seem to do anything.

Attachment	Size
openid_provider_sites_page.patch	3.92 KB

So I have improved the patch so that it actually works. I have also made the links clickable and improved the help by removing the negation in the text.

The original patch also removed the "No sites yet" behavior when the openid hasn't been used, that is not yet fixed and the form is likely to look odd when the openid_provider hasn't been used.

Attachment	Size
openid_provider_sites_page.patch	4.04 KB

I have built another patch which adds the "Deny" feature. It turns the checkboxes into radios and allows the user to deny access to some providers altogether.

Attachment	Size
openid_provider_sites_page.patch	10.26 KB

Small tweak: remove debugging code.

Attachment	Size
openid_provider_sites_page.patch	10.27 KB

I tested this on our provider against the D6 openid.module and it works well.

One last try: this one fixes the documentation in the form.

Attachment	Size
openid_provider_sites_page.patch	10.34 KB

I'm reworking this.

I think this is really my final jab at it now. I rerolled the patch so it applies cleanly again, cleaned up a little bit of code, fixed the way the form was handled, and clarified the options presented to the user when prompted.

Attachment	Size
openid_provider_sites_page.patch	10.97 KB

Tricky one: i forgot that the original behavior was to ask the user, I made sure this was still the case in this (hopefully) last patch.

Attachment	Size
openid_provider_sites_page.patch	10.99 KB

'sigh... So the patch was making it so that by default, the behaviour was to deny access (since '' = 0 in PHP), so I have fixed the default.

I also included some code to add watchdog entries when allowing access to the openid_provider.

Attachment	Size
openid_provider_sites_page.patch	11.41 KB

I tried #14 and was surprised that it stopped working. #15 works now when testing at http://openidenabled.com/resources/openid-test/checkup

Success Failure Incomplete
Associate (DH-SHA1 session) 1 0 0 Try again?
Successful checkid_setup 1 1 0 Try again?

The new interface also works. The only problem was that I had the setting on Ask, and then at the prompt said always allow, and even though it then always allowed, the interface was still set on Ask.

So this is weird. I was able to reproduce the issue you mentionned only once: one of my relaying parties was set to 'ask' but wasn't asking. I set it to 'allow', saved the page, set it to 'ask', and saved the page again and then it asked.

All the other RPs didn't behave this way.

This is rather weird, i don't think there's an issue with the code... and now i can't reproduce that issue..

Anyone else can provide a reliable test case for that issue?

I tested the patch and it works reliably.
When you try to test it, do a reinstall to make the schema up-to-date.

Actually, just running update.php should be enough.

Also, I must say I have witness some /instability/ regarding website approval. I could swear I have repeatedly approved identi.ca to always have access and it's *sometimes* prompting me, I'm not sure I understand why or if this behavior was present before the patch.

Setting the OpenID module up on drupal.org is a cornerstone of the redesign efforts. So making the server interface usable would be pretty important.

Actually, I'll reset this to 'needs work' because the issue i confirmed earlier is still there and very annoying. Basically, it's a regression: you always get prompted to accept the consumer even if you choose 'yes, always'.

Very annoying bug, we need to fix this.

I can confirm, i could reliably reproduce openid login issues. I get OpenID login failed messages all the time after applying the patch.

I could reproduce the problem described in #21, so I fixed the issue.
The problem was here:

(line 150)
TRUE is not appropiate here, because it can be multiple values. I replaced it to $rp->access and it works fine now.
Also I removed watchdog calls, I assume those messages mostly useful in a debugging environment.

Attachment	Size
396508_openid_provider_sites_page.patch	11.83 KB

Marked http://drupal.org/node/395010 as duplicate.

[snip] ... For example, would it make sense to be able to delete items from here? So that if for example you just test stuff out, it is not gonna litter your list of sites? Or should we just keep to the setting for automated assignments?

I'd like to see the question of whether or not a user can remove an entry addressed again. I looked through the code and didn't see an option for removing entries.