e the config it holds is null'ed instead of actually being updated at
that point.
The actual implementation is a bit more hairy but in broad lines it boils
down to the above, see:
com.sun.enterprise.security.jmac.config.ConfigHelper#getServerAuthConfig
Hope this helps.
Kind regards,
Arjan Tijms
y store, it can't handle login(), hence the
exception.
In case of logout(), next to what the server normally would do, the SAM's
cleanSubject() method has to be called.
Hope this helps.
Kind regards,
Arjan Tijms
--
View this message in context:
http://tomcat.10.x6.nabble.com/Consider-su
On Fri, Oct 16, 2015 at 4:27 PM, remm [via Tomcat]
wrote:
> 2015-10-16 16:11 GMT+02:00 Arjan Tijms <[hidden email]>:
> I was not talking about this future specification, since I never had a look.
Okay, my bad. I thought it was in reply to the JSR 375 work.
But what did you mean
ons
of all vendors and reporting behavioral differences and spec
violations to them. I've added many of those to a series of tests
here: https://github.com/javaee-samples/javaee7-samples/tree/master/jaspic
Some of those are likely to be fed back into the official TCK (which
for EE 7 is really s
deployed separately (via its own war).
Furthermore, the Security EG (JSR 375) is looking at building higher
level functionality that uses the JASPIC APIs as a base, so this may
possibly increase the demand for JASPIC in the future.
Kind regards,
Arjan Tijms
Hi there,
Haven't seen updates for some time here. Wonder what the current
status is and what exactly happened in the last months. Last commits
in the Tomcat repo are from 3 months ago.
Kind regards,
Arjan Tijms
On Thu, Jun 11, 2015 at 10:39 AM, markt [via Tomcat]
wrote:
> On 10/06
throw (AuthException) new AuthException().initCause(e);
}
}
Sounds good. Thanks for the tip.
>
You're welcome ;)
Kind regards,
Arjan Tijms
>
> Cheers,
>
> mark
>
> -
> To unsubscr
t
there is not a single standard configuration file. The only standardized
way is by using the AuthConfigFactory.
Kind regards,
Arjan Tijms
>
> > And what about JACC support? Geronimo uses JACC for authorization
> config,
> > what about Tomcat?
>
> Tomcat currently uses
> And what about JACC support? Geronimo uses JACC for authorization config,
> what about Tomcat?
>
JACC is an entirely different specification. It standardizes some of the
authorization decisions a container makes. It works in tandem with JASPIC,
but is not required by it. I don't thin
Hi,
Fjodor, for you (and everyone else interested) I've created a central hub
page for JASPIC on ZEEF.com, see https://jaspic.zeef.com
It contains links to existing implementations, various examples, articles,
and background.
Hope it helps!
Kind regards,
Arjan Tijms
On Mon, May 4, 2015
/omnisecurity/blob/master/src/main/java/org/omnifaces/security/jaspic/authmodules/BasicAuthModule.java
Calling out to the "identity store" is however not standardised yet (the
example code simply uses CDI) and has to be done in a Tomcat specific way.
Kind regards,
Arjan Tijms
On Monday, May 4, 20
Hi,
On Tue, Feb 10, 2015 at 8:34 PM, Mark Thomas-2 [via Tomcat]
wrote:
> If you do look at JBoss keep in mind it is GPL licensed and we need to
> be very careful that we don't end up with GPL'd code in Tomcat.
That's absolutely true. The code there shouldn't not be copied in any
way. It's only u
Hi,
On Tuesday, February 10, 2015, Fjodor Vershinin [via Tomcat] <
ml-node+s10n5029627...@n6.nabble.com> wrote:
> Hello!
> I am CS student and it looks like that this task is quite interesting. I
> would take it for GSOC if ASF organization will be selected. Currently I
> have some time to do res
to contact the guys who said to be working on a Tomcat JASPIC
bridge already. One of them had the intention to release his work as open
source, although he said he had to target Tomcat 6 specifically.
Kind regards,
Arjan Tijms
--
View this message in context:
http://tomcat.10.x6.nabble.com/C
TomEE didn't have JASPIC implemented yet, but Geronimo of course has.
markt wrote
> At the moment the main driver for this, in my view, is to provide an API
> for folks that want to do things like this:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=54503
Yes, I see. That'
> going to
> require JSR 196 support.
Just out of curiosity, but what would you think the reaction might be if
that was going to happen?
Kind regards,
Arjan Tijms
--
View this message in context:
http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-T
Joe Nathan wrote:
You should realize that PHP world is lot bigger than Java world!
I'm not really sure about that. For instance, even PHP web sites 'admit'
that Java is a great deal larger:
http://www.phpmag.net/magphpde/magphpde_news/psecom,id,27191,nodeid,5.html
Typically book stores (a
Tim Funk wrote:
Is this issue http://issues.apache.org/bugzilla/show_bug.cgi?id=41257
and http://issues.apache.org/bugzilla/show_bug.cgi?id=41258
I think these are the trouble:
Lines 2776-2777 in org.apache.jasper.compiler.Generator
TagAttributeInfo tai = attr.getTagAttributeInfo();
String ty
Whenever I try to use any EL (either $ or # syntax) in a taglib tag's
dynamic attribute in Tomcat 6.0.7, I get the following exception:
java.lang.NullPointerException
at
org.apache.jasper.compiler.Generator$GenerateVisitor.evaluateAttribute(Generator.java:2777)
at
org.apache.jasper.com
We're using a number of custom tags that accept JSF (deferred) EL
through dynamic attributes. In JSP 2.1 this is illegal. I therefore
tried to deactivate expression evaluation by escaping the #{ pattern,
but it seems that Tomcat 6.0.7 ignores this?
E.g.
at org.apache.jasper.compiler.Node$
20 matches
Mail list logo
