Understanding SELF

[DaveLillethun]

I'm trying to better understand the SELF keyword. Some trial-and-error showed me it doesn't work exactly the way I think it does... So what is the difference between these?

Code: Select all

Site .foo.com
Accept from SELF+
Deny

vs.

Code: Select all

Site .foo.com
Accept from SELF++
Deny

vs.

Code: Select all

Site .foo.com
Accept from .foo.com
Deny

I thought the latter two would be equivalent, at least in cases like these where there is only one Site token, but it seems they are not...

[Thrawn]

Code: Select all

Site .foo.com
Accept from SELF+
Deny

This will match the exact domain (foo.bar.example.com) but on any port and any protocol. Whereas SELF requires exact match of port and protocol.

I thought the latter two would be equivalent, at least in cases like these where there is only one Site token, but it seems they are not...

They should be AFAIK. What differences are you noticing?

[DaveLillethun]

You mean example.bar.foo.com, right? I thought ".foo.com" matched only domains ending in ".foo.com" (or that are exactly "foo.com").

In any case, I did understand that difference between SELF and SELF+ from the documentation. It's SELF+ vs. SELF++ that I didn't quite get...

As for the difference between the latter two...
I'm using a site called Obsidian Portal (www.obsidianportal.com) and they use rpxnow.com to assist in logins using OpenID provider (which I am using). I've found the following to work:

Code: Select all

Site .obsidianportal.com
Accept from .obsidianportal.com .rpxnow.com
Deny

Site .rpxnow.com
Accept from .rpxnow.com .obsidianportal.com # my OpenID provider is also listed on this line
Deny

But unfortunately, this does not seem to:

Code: Select all

Site .obsidianportal.com
Accept from SELF++ .rpxnow.com
Deny

Site .rpxnow.com
Accept from SELF++ .obsidianportal.com # my OpenID provider is also listed on this line
Deny

[Thrawn]

You mean example.bar.foo.com, right? I thought ".foo.com" matched only domains ending in ".foo.com" (or that are exactly "foo.com").
Yeah, I was just using that as an example of a full domain. You're right, 'example.foo.bar.com' would have better matched what you were discussing.

I'm using a site called Obsidian Portal (www.obsidianportal.com) and they use rpxnow.com to assist in logins using OpenID provider (which I am using). I've found the following to work:

Code: Select all

Site .obsidianportal.com
Accept from .obsidianportal.com .rpxnow.com
Deny

Site .rpxnow.com
Accept from .rpxnow.com .obsidianportal.com # my OpenID provider is also listed on this line
Deny

But unfortunately, this does not seem to:

Code: Select all

Site .obsidianportal.com
Accept from SELF++ .rpxnow.com
Deny

Site .rpxnow.com
Accept from SELF++ .obsidianportal.com # my OpenID provider is also listed on this line
Deny

Ah. I'm guessing this is related to putting multiple sites on one line, which has quirky (and necessary) behavior when sites redirect to each other.

Can you post the ABE message that occurs (from the Browser Console, Ctrl+Shift+J) when you use the second rule? You'll need to put it inside code tags. If the spam filter blocks it, then please send it to me or another moderator via private message.

[DaveLillethun]

Let's see what I can do here... So the error pops up when obsidianportal/rpxnow redirects me to my OpenID provider to log in. I log in there fine, then select the needed options and then click the continue button that _should_ send me back to obsidianportal and log me in. When I click on that button I get the error:

Code: Select all

[17:05:21.385] [ABE] <.rpxnow.com> Deny on {GET https://obsidianportal.rpxnow.com/xdcomm#sanitized <<< https://obsidianportal.rpxnow.com/openid/finish?sanitized, https://my_openid_provider.com/directedIdentity?target=render, https://my_openid_provider.com/directedIdentityAction.do - 6}
USER rule:
Site .rpxnow.com
Accept from SELF++ .obsidianportal.com .my_openid_provider.com
Deny

I sanitized quite a lot because I'm not sure what kind of information might be hidden in those complex URLs the OpenID stuff uses... I'll PM you the unsanitized version.
As I mentioned, if I just replace "SELF++" with ".rpxnow.com" then it works fine.

[DaveLillethun]

More info, after I poked around a bit...
If I fix that rule so it works, then I click on the continue button, it seems to actually return to obsidianportal but fails to actually load the page there and I get this error:

Code: Select all

[17:19:33.597] [ABE] <.obsidianportal.com> Deny on {GET http://www.obsidianportal.com/profile/my_username <<< http://www.obsidianportal.com/sessions/create_rpx?remember_me=1, https://obsidianportal.rpxnow.com/redirect?loc=4912ee55a3e431f780bd393237b7b6023aff2e1b - 6}
USER rule:
Site .obsidianportal.com
Accept from SELF++ .rpxnow.com
Deny

Just sanitized my username in the URL. Everything else looks harmless enough.

(Although I did change one thing besides fixing the one rule... Last time I didn't click on the "Remember Me" button and this time I did. I don't think that affected anything important, though...)

However, this time, if I just go to the top-level obsidianportal page and reload, I am indeed logged in. So the login worked; just failed returning me to the obsidianportal site and refreshing that page....

[Thrawn]

From those posts, I can see that you are indeed hitting issues with multiple source sites, probably from a redirection. Notice that after the '<<<', there are two sites, separated by a comma. From what I understand, one of these sites is redirecting you to the other, which then redirects you to the end goal, and ABE takes account of both sites when deciding whether to block or allow the request.

I'm not sure of all the subtleties of how this works, and I think it probably needs a cleanup sometime when Giorgio gets time. But in the meantime, I'd recommend just using the leading dot version instead of SELF++.

You could also compact your rule to:

Code: Select all

Site .obsidianportal.com .rpxnow.com
Accept from .obsidianportal.com .rpxnow.com .my_openid_provider.com
Deny

[DaveLillethun]

Thanks, I'll do that for now. I realized I could get it working; I was more just asking out of curiosity since I thought the two should be the same but they didn't behave that way - I thought my understanding might have been wrong.

I may also compact them like you suggest. I initially had them separate so I could experiment with the rules for each domain separately. That's no longer needed now that I know what rules I need... Although, arguing for the other side, rpxnow is a third-part service and it's possible another, unrelated site I go to someday may also use rpxnow. So then I'd have a choice: three rules (each of the two sites, plus rpxnow), or bundle everything together including the two unrelated sites. But I can also cross that bridge when I come to it...

So just a quick question on the logging syntax... when it says "<<< a, b" does that mean 'a' redirected to 'b' which tried to load the bit before the arrow, or 'b' redirected to 'a' which tried to load the bit before the arrow, or I got all wrong and it means something else? (Just so I know how to read these messages in the future.)

[Thrawn]

So just a quick question on the logging syntax... when it says "<<< a, b" does that mean 'a' redirected to 'b' which tried to load the bit before the arrow, or 'b' redirected to 'a' which tried to load the bit before the arrow, or I got all wrong and it means something else? (Just so I know how to read these messages in the future.)

Actually, checking more carefully, I think it's "b sent a request to a, which redirected to the bit before the arrow".