Hi Erik
I've tried to subscribe to the mailing list, but sourceforge doesn't like my ISP
for some reason.. I'm looking into it, but in the meantime I thought I would
just e-mail you.
I've subscribed you manually. SF recently changed their spam filtering
rules. Last week I too was unable to post to this list because, when you
post, their server appears to evaluate the From: address. It connects to
the From: address' mail server and does a RCPT TO. In my case, my server
rejected SF's mail server doing a RCPT TO because SF's mail server was
in the Spamcop real time block list. To get around it, I had to add SF's
mail server to my whitelist of allowed mail servers. Thus it could RCPT
TO (despite being blacklisted in Spamcop) and I could send messages. SF
really need to address the spam issue. Every day I need to manually
delete at least four spam messages that people try to send to this list.
Even their new RCPT TO of the From: address isn't a solution, because
the offending From: addresses are probably valid (being customer service
addresses from well-known companies like PayPal and eBay). A solution
that would work is replying to all messages posted by non-members of a
list, and requiring them to manually confirm via an obfuscated image.
This would automate a validation step that currently has to be manually
done by project admins.
There was a local variable added to HttpSessionContextIntegrationFilter called
httpSessionExistedAtStartOfRequest. This is a great idea, but it wasn't quite
enough for us. In order to facilitate a proper logout, we found the need to
actually verify the sessionIDs of the session at the start & end of the filter,
to see if they had changed. When we invalidated the current session, there
were things in place that would cause a new one to be created- then ACEGI would
pick up the new session and store the user in it. I'm not sure if that's
expected behavior or not, but for us it was undesirable. Here is a patch we
made that catches this scenario and makes sure the user stays logged out. (diff
is against v0.8.1)
Could you please explain in a little more detail why the existing
approach doesn't work properly for you? I am not sure this is an Acegi
Security issue. The "things in place that would cause a new one to be
created" probably need addressing instead. If you are invalidating a
session, and then something else is re-generating it, I don't think
making Acegi Security detect this and respond in a special way is the
optimal approach. You'll have superfluous sessions laying around at
best, so I'd firstly encourage looking at whatever is re-creating the
session.
Cheers
Ben
-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
_______________________________________________
Home: http://acegisecurity.sourceforge.net
Acegisecurity-developer mailing list
Acegisecurity-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
