You need Java to execute the war file.
java -jar cas.war
On Nov 14, 2017 08:39, "Adam Causey" wrote:
> Misagh,
>
> If I try to run it as an executable I get the following errors:
>
>
> ./cas.war: line 1: PK: command not found
> ./cas.war: line 2:1}iK: command not found
> ./cas.war: line 3:1}iK?
timeUnit: HOURS
}
authorizedToReleaseCredentialPassword: false
authorizedToReleaseProxyGrantingTicket: false
excludeDefaultAttributes: false
}
multifactorPolicy:
{
@class:
org.apereo.cas.services.DefaultRegisteredServiceMultifactorPolicy
failureMode: CLOSED
bypassEnabled: false
}
accessStrategy:
the user has them, but I have not seen them yet.
You can reference them in the attribute release policy as described above,
and map them to other names
using org.apereo.cas.services.ReturnMappedAttributeReleasePolicy if you
need them.
Carlos
Carlos Fernandez | Solutions Architect
cfernan...@cor
I more or less ran into it by accident. I had a mashup of the basic pom.xml
from the overlay template and some bits from our old overlay and was trying
to troubleshoot why Maven was not copying my views customizations from
src/main/resources/ but would copy them (to two different locations in the
W
Where does project/build/resources/resource/directory in your pom.xml point
to? In my case I had to explicitly add this to project/build:
src/main/resources
Once I did that Maven merged my changes from the overlay into the WAR file.
Best regards,
--
Carlos M. Fernández
Enter
Hi, Erik,
I had a similar problem using Hazelcast as the storage service for a
Shibboleth installation. I found that the member list should only include
*other* servers, not the local host. In your case, on appdev-523 should
have cas.ticket.registry.hazelcast.cluster.members set to
appdev-524.wic
01
On Tue, Jul 11, 2017 at 2:14 PM, Daniel Fisher wrote:
> On Mon, Jul 10, 2017 at 6:21 PM, Carlos Fernandez
> wrote:
>
>> 2017-07-10 13:02:40,171 DEBUG
>> [org.ldaptive.auth.PooledBindAuthenticationHandler]
>> - > thenticationCriteria@530348177::dn=uid=
Systems Manager
*Saint Joseph’s University*
Philadelphia PA 19131
T: +1 610 660 1501
On Mon, Jul 10, 2017 at 6:21 PM, Carlos Fernandez wrote:
> I included a link to the logs here: https://drive.google.com/a/
> sju.edu/file/d/0B-j8Pz4AXloHczFURXdhaGYwU1E/view?usp=drive_web
>
> Basica
los M. Fernández
Enterprise Systems Manager
*Saint Joseph’s University*
Philadelphia PA 19131
T: +1 610 660 1501
On Mon, Jul 10, 2017 at 5:23 PM, Daniel Fisher wrote:
> On Mon, Jul 10, 2017 at 12:44 PM, Carlos Fernandez
> wrote:
>
>> 2017-07-10 12:26:33,172 WARN [org.ldapt
0 660 1501
On Mon, Jul 10, 2017 at 4:02 PM, Tim McLaughlin
wrote:
> I'm checking this out now. I'm on 5.0.3 so I'll rebuild with 5.0.7 and
> see if we still see the issue...
>
>
>
> I've added:
>
> cas.authn.ldap[0].poolPassivator=CLOSE
>
>
>
prise Systems Manager
*Saint Joseph’s University*
Philadelphia PA 19131
T: +1 610 660 1501
On Mon, Jul 10, 2017 at 3:08 PM, Carlos Fernandez wrote:
> I found a thread in the Google group for ldaptive that describes a
> scenario similar to ours. Could anyone confirm that it's re
rsity*
Philadelphia PA 19131
T: +1 610 660 1501
On Mon, Jul 10, 2017 at 2:16 PM, Carlos Fernandez wrote:
> Tim,
>
> Knowing that the same issue happens elsewhere makes me feel much better
> about my sanity. Now to figure out why it happens. I have an inkling that
> ldaptive is causing this,
wn the timing), this message begins.
>
>
>
> I'm not seeing this in our Test or Dev deployments, but usage of those is
> very small compared to Production, so I'm assuming this is tied to load or
> the number of principals created or something...
>
>
>
> Tim
stems Manager
*Saint Joseph’s University*
Philadelphia PA 19131
T: +1 610 660 1501
On Mon, Jul 10, 2017 at 12:44 PM, Carlos Fernandez wrote:
> Good afternoon,
>
> We recently upgraded to CAS 5.0.5 in production and have now run into an
> issue where CAS fails to authenticate users. It se
Good afternoon,
We recently upgraded to CAS 5.0.5 in production and have now run into an
issue where CAS fails to authenticate users. It seems that whenever CAS
fails the authentication attempt when tries to check out a connection from
the LDAP pool and Ldaptive fails the checkout validation. This
I'm in the process of doing the same -- we have finished testing already
and will go live on Saturday. Since nothing carries over from the 3.5
series to 5.0, you'll be better off starting a CAS 5.0 implementation from
scratch on a separate system and build it up to the necessary level of
functional
I'm trying to trace a mild issue with my CAS 5.0.5 overlay in which a
logged in user returns with a new service URL and gets the login page
again, despite global renew being set to false, and the service not having
renew set in the registry. I found the following entries (attached) in my
log file o
Adam,
In a somewhat related issue, I had a problem where nothing I added to
src/main/resources/ would get bundled in the WAR file. I traced this to the
build resources entry in the pom.xml. So now I have this:
src/main/resources
And now my resources (including bootstra
There's an old thread in which Scott Battaglia explained why that's not
supported, but mainly it's because the application should not be aware of
the user's password.
http://jasig.275507.n4.nabble.com/authenticating-a-user-via-URL-parameters-td2067870.html
His suggestion of interacting with CAS p
19 matches
Mail list logo
