You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shiro.apache.org by Les Hazlewood <lh...@apache.org> on 2010/02/19 15:21:21 UTC
Re: svn commit: r911722 - in /incubator/shiro/trunk/samples/spring-client:
./ src/ src/main/ src/main/java/ src/main/java/org/ src/main/java/org/apache/
src/main/java/org/apache/shiro/ src/main/java/org/apache/shiro/samples/
src/main/java/org/apache/
This is awesome, thanks!
On Fri, Feb 19, 2010 at 2:25 AM, <ka...@apache.org> wrote:
> Author: kaosko
> Date: Fri Feb 19 07:25:50 2010
> New Revision: 911722
>
> URL: http://svn.apache.org/viewvc?rev=911722&view=rev
> Log:
> SHIRO-89: Sample Spring Application - WebStart won't launch
> - Refactor Spring sample client from Spring sample into its own module to make packaging & dependency management easier and simpler. Work in progress
>
> Added:
> incubator/shiro/trunk/samples/spring-client/
> incubator/shiro/trunk/samples/spring-client/pom.xml
> incubator/shiro/trunk/samples/spring-client/src/
> incubator/shiro/trunk/samples/spring-client/src/main/
> incubator/shiro/trunk/samples/spring-client/src/main/java/
> incubator/shiro/trunk/samples/spring-client/src/main/java/org/
> incubator/shiro/trunk/samples/spring-client/src/main/java/org/apache/
> incubator/shiro/trunk/samples/spring-client/src/main/java/org/apache/shiro/
> incubator/shiro/trunk/samples/spring-client/src/main/java/org/apache/shiro/samples/
> incubator/shiro/trunk/samples/spring-client/src/main/java/org/apache/shiro/samples/spring/
> incubator/shiro/trunk/samples/spring-client/src/main/java/org/apache/shiro/samples/spring/DefaultSampleManager.java
> incubator/shiro/trunk/samples/spring-client/src/main/java/org/apache/shiro/samples/spring/SampleManager.java
> incubator/shiro/trunk/samples/spring-client/src/main/java/org/apache/shiro/samples/spring/ui/
> incubator/shiro/trunk/samples/spring-client/src/main/java/org/apache/shiro/samples/spring/ui/WebStartDriver.java
> incubator/shiro/trunk/samples/spring-client/src/main/java/org/apache/shiro/samples/spring/ui/WebStartView.java
> incubator/shiro/trunk/samples/spring-client/src/main/resources/
> incubator/shiro/trunk/samples/spring-client/src/main/resources/logo.png (with props)
> incubator/shiro/trunk/samples/spring-client/src/main/resources/webstart.spring.xml
>
> Added: incubator/shiro/trunk/samples/spring-client/pom.xml
> URL: http://svn.apache.org/viewvc/incubator/shiro/trunk/samples/spring-client/pom.xml?rev=911722&view=auto
> ==============================================================================
> --- incubator/shiro/trunk/samples/spring-client/pom.xml (added)
> +++ incubator/shiro/trunk/samples/spring-client/pom.xml Fri Feb 19 07:25:50 2010
> @@ -0,0 +1,55 @@
> +<?xml version="1.0" encoding="UTF-8"?>
> +<!--
> + ~ Licensed to the Apache Software Foundation (ASF) under one
> + ~ or more contributor license agreements. See the NOTICE file
> + ~ distributed with this work for additional information
> + ~ regarding copyright ownership. The ASF licenses this file
> + ~ to you under the Apache License, Version 2.0 (the
> + ~ "License"); you may not use this file except in compliance
> + ~ with the License. You may obtain a copy of the License at
> + ~
> + ~ http://www.apache.org/licenses/LICENSE-2.0
> + ~
> + ~ Unless required by applicable law or agreed to in writing,
> + ~ software distributed under the License is distributed on an
> + ~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
> + ~ KIND, either express or implied. See the License for the
> + ~ specific language governing permissions and limitations
> + ~ under the License.
> + -->
> +<!--suppress osmorcNonOsgiMavenDependency -->
> +<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> + xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
> +
> + <parent>
> + <groupId>org.apache.shiro.samples</groupId>
> + <artifactId>shiro-samples</artifactId>
> + <version>1.0-incubating-SNAPSHOT</version>
> + </parent>
> +
> + <modelVersion>4.0.0</modelVersion>
> + <artifactId>samples-spring-client</artifactId>
> + <name>Apache Shiro :: Samples :: Spring Client</name>
> + <description>Spring Client used by Spring Sample webapplication</description>
> + <packaging>jar</packaging>
> +
> + <dependencies>
> + <dependency>
> + <groupId>org.apache.shiro</groupId>
> + <artifactId>shiro-core</artifactId>
> + </dependency>
> + <dependency>
> + <groupId>org.apache.shiro</groupId>
> + <artifactId>shiro-spring</artifactId>
> + </dependency>
> + <dependency>
> + <groupId>org.apache.shiro</groupId>
> + <artifactId>shiro-web</artifactId>
> + </dependency>
> + <dependency>
> + <groupId>org.springframework</groupId>
> + <artifactId>spring</artifactId>
> + </dependency>
> + </dependencies>
> +
> +</project>
>
> Added: incubator/shiro/trunk/samples/spring-client/src/main/java/org/apache/shiro/samples/spring/DefaultSampleManager.java
> URL: http://svn.apache.org/viewvc/incubator/shiro/trunk/samples/spring-client/src/main/java/org/apache/shiro/samples/spring/DefaultSampleManager.java?rev=911722&view=auto
> ==============================================================================
> --- incubator/shiro/trunk/samples/spring-client/src/main/java/org/apache/shiro/samples/spring/DefaultSampleManager.java (added)
> +++ incubator/shiro/trunk/samples/spring-client/src/main/java/org/apache/shiro/samples/spring/DefaultSampleManager.java Fri Feb 19 07:25:50 2010
> @@ -0,0 +1,106 @@
> +/*
> + * Licensed to the Apache Software Foundation (ASF) under one
> + * or more contributor license agreements. See the NOTICE file
> + * distributed with this work for additional information
> + * regarding copyright ownership. The ASF licenses this file
> + * to you under the Apache License, Version 2.0 (the
> + * "License"); you may not use this file except in compliance
> + * with the License. You may obtain a copy of the License at
> + *
> + * http://www.apache.org/licenses/LICENSE-2.0
> + *
> + * Unless required by applicable law or agreed to in writing,
> + * software distributed under the License is distributed on an
> + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
> + * KIND, either express or implied. See the License for the
> + * specific language governing permissions and limitations
> + * under the License.
> + */
> +package org.apache.shiro.samples.spring;
> +
> +import org.slf4j.Logger;
> +import org.slf4j.LoggerFactory;
> +
> +import org.apache.shiro.SecurityUtils;
> +import org.apache.shiro.session.Session;
> +import org.apache.shiro.subject.Subject;
> +
> +
> +/**
> + * Default implementation of the {@link SampleManager} interface that stores
> + * and retrieves a value from the user's session.
> + *
> + * @author Jeremy Haile
> + * @since 0.1
> + */
> +public class DefaultSampleManager implements SampleManager {
> +
> + /*--------------------------------------------
> + | C O N S T A N T S |
> + ============================================*/
> + /**
> + * Key used to store the value in the user's session.
> + */
> + private static final String VALUE_KEY = "sample_value";
> +
> + /*--------------------------------------------
> + | I N S T A N C E V A R I A B L E S |
> + ============================================*/
> + private static final Logger log = LoggerFactory.getLogger(DefaultSampleManager.class);
> +
> + /*--------------------------------------------
> + | C O N S T R U C T O R S |
> + ============================================*/
> +
> + /*--------------------------------------------
> + | A C C E S S O R S / M O D I F I E R S |
> + ============================================*/
> +
> + /*--------------------------------------------
> + | M E T H O D S |
> + ============================================*/
> +
> + public String getValue() {
> + String value = null;
> +
> + Subject subject = SecurityUtils.getSubject();
> + Session session = subject.getSession(false);
> + if (session != null) {
> + value = (String) session.getAttribute(VALUE_KEY);
> + if (log.isDebugEnabled()) {
> + log.debug("retrieving session key [" + VALUE_KEY + "] with value [" + value + "] on session with id [" + session.getId() + "]");
> + }
> + }
> +
> + return value;
> + }
> +
> + public void setValue(String newValue) {
> + Subject subject = SecurityUtils.getSubject();
> + Session session = subject.getSession();
> +
> + if (log.isDebugEnabled()) {
> + log.debug("saving session key [" + VALUE_KEY + "] with value [" + newValue + "] on session with id [" + session.getId() + "]");
> + }
> +
> + session.setAttribute(VALUE_KEY, newValue);
> + }
> +
> + public void secureMethod1() {
> + if (log.isInfoEnabled()) {
> + log.info("Secure method 1 called...");
> + }
> + }
> +
> + public void secureMethod2() {
> + if (log.isInfoEnabled()) {
> + log.info("Secure method 2 called...");
> + }
> + }
> +
> + public void secureMethod3() {
> + if (log.isInfoEnabled()) {
> + log.info("Secure method 3 called...");
> + }
> + }
> +}
>
> Added: incubator/shiro/trunk/samples/spring-client/src/main/java/org/apache/shiro/samples/spring/SampleManager.java
> URL: http://svn.apache.org/viewvc/incubator/shiro/trunk/samples/spring-client/src/main/java/org/apache/shiro/samples/spring/SampleManager.java?rev=911722&view=auto
> ==============================================================================
> --- incubator/shiro/trunk/samples/spring-client/src/main/java/org/apache/shiro/samples/spring/SampleManager.java (added)
> +++ incubator/shiro/trunk/samples/spring-client/src/main/java/org/apache/shiro/samples/spring/SampleManager.java Fri Feb 19 07:25:50 2010
> @@ -0,0 +1,65 @@
> +/*
> + * Licensed to the Apache Software Foundation (ASF) under one
> + * or more contributor license agreements. See the NOTICE file
> + * distributed with this work for additional information
> + * regarding copyright ownership. The ASF licenses this file
> + * to you under the Apache License, Version 2.0 (the
> + * "License"); you may not use this file except in compliance
> + * with the License. You may obtain a copy of the License at
> + *
> + * http://www.apache.org/licenses/LICENSE-2.0
> + *
> + * Unless required by applicable law or agreed to in writing,
> + * software distributed under the License is distributed on an
> + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
> + * KIND, either express or implied. See the License for the
> + * specific language governing permissions and limitations
> + * under the License.
> + */
> +package org.apache.shiro.samples.spring;
> +
> +import org.apache.shiro.authz.annotation.RequiresPermissions;
> +import org.apache.shiro.authz.annotation.RequiresRoles;
> +
> +
> +/**
> + * Business manager interface used for sample application.
> + *
> + * @author Jeremy Haile
> + * @since 0.1
> + */
> +public interface SampleManager {
> +
> + /**
> + * Returns the value stored in the user's session.
> + *
> + * @return the value.
> + */
> + String getValue();
> +
> +
> + /**
> + * Sets a value to be stored in the user's session.
> + *
> + * @param newValue the new value to store in the user's session.
> + */
> + void setValue(String newValue);
> +
> + /**
> + * Method that requires <tt>role1</tt> in order to be invoked.
> + */
> + @RequiresRoles("role1")
> + void secureMethod1();
> +
> + /**
> + * Method that requires <tt>role2</tt> in order to be invoked.
> + */
> + @RequiresRoles("role2")
> + void secureMethod2();
> +
> + /**
> + * Method that requires <tt>permission1</tt> in order to be invoked.
> + */
> + @RequiresPermissions("permission2")
> + void secureMethod3();
> +}
>
> Added: incubator/shiro/trunk/samples/spring-client/src/main/java/org/apache/shiro/samples/spring/ui/WebStartDriver.java
> URL: http://svn.apache.org/viewvc/incubator/shiro/trunk/samples/spring-client/src/main/java/org/apache/shiro/samples/spring/ui/WebStartDriver.java?rev=911722&view=auto
> ==============================================================================
> --- incubator/shiro/trunk/samples/spring-client/src/main/java/org/apache/shiro/samples/spring/ui/WebStartDriver.java (added)
> +++ incubator/shiro/trunk/samples/spring-client/src/main/java/org/apache/shiro/samples/spring/ui/WebStartDriver.java Fri Feb 19 07:25:50 2010
> @@ -0,0 +1,36 @@
> +/*
> + * Licensed to the Apache Software Foundation (ASF) under one
> + * or more contributor license agreements. See the NOTICE file
> + * distributed with this work for additional information
> + * regarding copyright ownership. The ASF licenses this file
> + * to you under the Apache License, Version 2.0 (the
> + * "License"); you may not use this file except in compliance
> + * with the License. You may obtain a copy of the License at
> + *
> + * http://www.apache.org/licenses/LICENSE-2.0
> + *
> + * Unless required by applicable law or agreed to in writing,
> + * software distributed under the License is distributed on an
> + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
> + * KIND, either express or implied. See the License for the
> + * specific language governing permissions and limitations
> + * under the License.
> + */
> +package org.apache.shiro.samples.spring.ui;
> +
> +import org.springframework.context.support.ClassPathXmlApplicationContext;
> +
> +/**
> + * Driver class used to launch the web start application by loading a
> + * Spring application context. Once the Spring application context is
> + * loaded, the initialization of the {@link WebStartView} does the rest.
> + *
> + * @author Jeremy Haile
> + * @since 0.1
> + */
> +public class WebStartDriver {
> +
> + public static void main(String[] args) {
> + new ClassPathXmlApplicationContext("webstart.spring.xml");
> + }
> +}
>
> Added: incubator/shiro/trunk/samples/spring-client/src/main/java/org/apache/shiro/samples/spring/ui/WebStartView.java
> URL: http://svn.apache.org/viewvc/incubator/shiro/trunk/samples/spring-client/src/main/java/org/apache/shiro/samples/spring/ui/WebStartView.java?rev=911722&view=auto
> ==============================================================================
> --- incubator/shiro/trunk/samples/spring-client/src/main/java/org/apache/shiro/samples/spring/ui/WebStartView.java (added)
> +++ incubator/shiro/trunk/samples/spring-client/src/main/java/org/apache/shiro/samples/spring/ui/WebStartView.java Fri Feb 19 07:25:50 2010
> @@ -0,0 +1,168 @@
> +/*
> + * Licensed to the Apache Software Foundation (ASF) under one
> + * or more contributor license agreements. See the NOTICE file
> + * distributed with this work for additional information
> + * regarding copyright ownership. The ASF licenses this file
> + * to you under the Apache License, Version 2.0 (the
> + * "License"); you may not use this file except in compliance
> + * with the License. You may obtain a copy of the License at
> + *
> + * http://www.apache.org/licenses/LICENSE-2.0
> + *
> + * Unless required by applicable law or agreed to in writing,
> + * software distributed under the License is distributed on an
> + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
> + * KIND, either express or implied. See the License for the
> + * specific language governing permissions and limitations
> + * under the License.
> + */
> +package org.apache.shiro.samples.spring.ui;
> +
> +import java.awt.*;
> +import java.awt.event.ActionEvent;
> +import java.awt.event.ActionListener;
> +import java.awt.event.WindowAdapter;
> +import java.awt.event.WindowEvent;
> +import javax.swing.*;
> +
> +import org.springframework.beans.factory.InitializingBean;
> +import org.springframework.core.io.ClassPathResource;
> +
> +import org.apache.shiro.authz.AuthorizationException;
> +import org.apache.shiro.samples.spring.DefaultSampleManager;
> +import org.apache.shiro.samples.spring.SampleManager;
> +
> +
> +/**
> + * Simple web start application that helps to demo single sign-on and
> + * remoting authorization using Shiro. The injected <tt>SampleManager</tt>
> + * is hosted by the Spring sample web application and remotely invoked
> + * when the buttons in this view are clicked.
> + *
> + * @author Jeremy Haile
> + * @since 0.1
> + */
> +public class WebStartView implements ActionListener, InitializingBean {
> +
> + /*--------------------------------------------
> + | C O N S T A N T S |
> + ============================================*/
> +
> + /*--------------------------------------------
> + | I N S T A N C E V A R I A B L E S |
> + ============================================*/
> + private SampleManager sampleManager;
> + private JTextField valueField;
> + private JButton saveButton;
> + private JButton refreshButton;
> + private JButton secureMethod1Button;
> + private JButton secureMethod2Button;
> + private JButton secureMethod3Button;
> + private JFrame frame;
> +
> + /*--------------------------------------------
> + | C O N S T R U C T O R S |
> + ============================================*/
> +
> + /*--------------------------------------------
> + | A C C E S S O R S / M O D I F I E R S |
> + ============================================*/
> +
> + public void setSampleManager(SampleManager sampleManager) {
> + this.sampleManager = sampleManager;
> + }
> +
> + /*--------------------------------------------
> + | M E T H O D S |
> + ============================================*/
> + public void afterPropertiesSet() throws Exception {
> + ClassPathResource resource = new ClassPathResource("logo.png");
> + ImageIcon icon = new ImageIcon(resource.getURL());
> + JLabel logo = new JLabel(icon);
> +
> + valueField = new JTextField(20);
> + updateValueLabel();
> +
> + saveButton = new JButton("Save Value");
> + saveButton.addActionListener(this);
> +
> + refreshButton = new JButton("Refresh Value");
> + refreshButton.addActionListener(this);
> +
> + JPanel valuePanel = new JPanel(new FlowLayout(FlowLayout.CENTER));
> + valuePanel.add(valueField);
> + valuePanel.add(saveButton);
> + valuePanel.add(refreshButton);
> +
> + secureMethod1Button = new JButton("Method #1");
> + secureMethod1Button.addActionListener(this);
> +
> + secureMethod2Button = new JButton("Method #2");
> + secureMethod2Button.addActionListener(this);
> +
> + secureMethod3Button = new JButton("Method #3");
> + secureMethod3Button.addActionListener(this);
> +
> + JPanel methodPanel = new JPanel(new FlowLayout(FlowLayout.CENTER));
> + methodPanel.add(secureMethod1Button);
> + methodPanel.add(secureMethod2Button);
> + methodPanel.add(secureMethod3Button);
> +
> + frame = new JFrame("Apache Shiro Sample Application");
> + frame.setSize(500, 200);
> +
> + Container panel = frame.getContentPane();
> + panel.setLayout(new BorderLayout());
> + panel.add(logo, BorderLayout.NORTH);
> + panel.add(valuePanel, BorderLayout.CENTER);
> + panel.add(methodPanel, BorderLayout.SOUTH);
> +
> + frame.setVisible(true);
> + frame.addWindowListener(new WindowAdapter() {
> + public void windowClosing(WindowEvent e) {
> + System.exit(0);
> + }
> + });
> + }
> +
> + private void updateValueLabel() {
> + valueField.setText(sampleManager.getValue());
> + }
> +
> + public void actionPerformed(ActionEvent e) {
> + try {
> +
> + if (e.getSource() == saveButton) {
> + sampleManager.setValue(valueField.getText());
> +
> + } else if (e.getSource() == refreshButton) {
> + updateValueLabel();
> +
> + } else if (e.getSource() == secureMethod1Button) {
> + sampleManager.secureMethod1();
> + JOptionPane.showMessageDialog(frame, "Method #1 successfully called.", "Success", JOptionPane.INFORMATION_MESSAGE);
> +
> + } else if (e.getSource() == secureMethod2Button) {
> + sampleManager.secureMethod2();
> + JOptionPane.showMessageDialog(frame, "Method #2 successfully called.", "Success", JOptionPane.INFORMATION_MESSAGE);
> + } else if (e.getSource() == secureMethod3Button) {
> + sampleManager.secureMethod3();
> + JOptionPane.showMessageDialog(frame, "Method #3 successfully called.", "Success", JOptionPane.INFORMATION_MESSAGE);
> +
> + } else {
> + throw new RuntimeException("Unexpected action event from source: " + e.getSource());
> + }
> +
> + } catch (AuthorizationException ae) {
> + JOptionPane.showMessageDialog(frame, "Unauthorized to perform action: " + ae.getMessage(), "Unauthorized", JOptionPane.WARNING_MESSAGE);
> + }
> + }
> +
> + public static void main(String[] args) throws Exception {
> + WebStartView test = new WebStartView();
> + test.setSampleManager(new DefaultSampleManager());
> + test.afterPropertiesSet();
> + }
> +
> +
> +}
>
> Added: incubator/shiro/trunk/samples/spring-client/src/main/resources/logo.png
> URL: http://svn.apache.org/viewvc/incubator/shiro/trunk/samples/spring-client/src/main/resources/logo.png?rev=911722&view=auto
> ==============================================================================
> Binary file - no diff available.
>
> Propchange: incubator/shiro/trunk/samples/spring-client/src/main/resources/logo.png
> ------------------------------------------------------------------------------
> svn:mime-type = application/octet-stream
>
> Added: incubator/shiro/trunk/samples/spring-client/src/main/resources/webstart.spring.xml
> URL: http://svn.apache.org/viewvc/incubator/shiro/trunk/samples/spring-client/src/main/resources/webstart.spring.xml?rev=911722&view=auto
> ==============================================================================
> --- incubator/shiro/trunk/samples/spring-client/src/main/resources/webstart.spring.xml (added)
> +++ incubator/shiro/trunk/samples/spring-client/src/main/resources/webstart.spring.xml Fri Feb 19 07:25:50 2010
> @@ -0,0 +1,42 @@
> +<?xml version="1.0" encoding="UTF-8"?>
> +<!--
> + ~ Licensed to the Apache Software Foundation (ASF) under one
> + ~ or more contributor license agreements. See the NOTICE file
> + ~ distributed with this work for additional information
> + ~ regarding copyright ownership. The ASF licenses this file
> + ~ to you under the Apache License, Version 2.0 (the
> + ~ "License"); you may not use this file except in compliance
> + ~ with the License. You may obtain a copy of the License at
> + ~
> + ~ http://www.apache.org/licenses/LICENSE-2.0
> + ~
> + ~ Unless required by applicable law or agreed to in writing,
> + ~ software distributed under the License is distributed on an
> + ~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
> + ~ KIND, either express or implied. See the License for the
> + ~ specific language governing permissions and limitations
> + ~ under the License.
> + -->
> +<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" "http://www.springframework.org/dtd/spring-beans.dtd">
> +
> +<!--
> + - Application context for Shiro WebStart sample application
> + -->
> +<beans>
> +
> + <bean id="webStartView"
> + class="org.apache.shiro.samples.spring.ui.WebStartView">
> + <property name="sampleManager" ref="sampleManager"/>
> + </bean>
> +
> + <bean id="sampleManager"
> + class="org.springframework.remoting.httpinvoker.HttpInvokerProxyFactoryBean">
> + <property name="serviceUrl" value="http://localhost:8080/shiro-spring/remoting/sampleManager"/>
> + <property name="serviceInterface" value="org.apache.shiro.samples.spring.SampleManager"/>
> + <property name="remoteInvocationFactory" ref="secureRemoteInvocationFactory"/>
> + </bean>
> +
> + <bean id="secureRemoteInvocationFactory"
> + class="org.apache.shiro.spring.remoting.SecureRemoteInvocationFactory"/>
> +
> +</beans>
>
>
>
Re: svn commit: r911722 - in /incubator/shiro/trunk/samples/spring-client:
./ src/ src/main/ src/main/java/ src/main/java/org/ src/main/java/org/apache/
src/main/java/org/apache/shiro/ src/main/java/org/apache/shiro/samples/
src/main/java/org/apache/
Posted by Les Hazlewood <lh...@apache.org>.
Cool - sounds good!
On Mon, May 10, 2010 at 1:05 PM, Kalle Korhonen
<ka...@gmail.com> wrote:
> On Mon, May 10, 2010 at 12:41 PM, Les Hazlewood <lh...@apache.org> wrote:
>>>> I'll take a peek at the authentication issue. The idea was that you
>>>> would authenticate via the webapp first (JSP) and then launch the
>>>> webstart app. So, the /remoting/** = authc, ... line was added as an
>>>> example of a secure app that can only be used if already
>>>> authenticated. Does this make sense?
>>>
>>> Right, you can only launch the webstart app if you are logged in. But
>>> the webstart app doesn't share the same session, or specifically,
>>> doesn't carry the same session cookie in the http remote invocation
>>> headers as the user's browser, so the request never reaches the
>>> remoting servlet. Either there was some additional mechanism to deal
>>> with that but it was lost along the way or I just don't understand how
>>> this configuration could work. The SecureRemoteInvocationExecutor
>>> itself does the expected thing, creating the subject from the session
>>> id argument if the request is allowed to progress that far.
>>
>> Ah, I see now. I think having /remoting/** = authc doesn't make sense
>> then. I think it probably makes more sense that a client should be
>> able to execute a remote invocation at any point in the Subject's
>> interaction with the system and rely on things like annotations or
>> code checks to assert a user must be authenticated for a certain
>> method.
>> Then, if any filter would be applied to /remoting/** it would probably
>> more likely be something like an SSL filter or IP filter to ensure the
>> request is either secure, or comes from a certain IP or IP range or
>> something like that.
>> What do you think?
>
> Right, that's how I figured it, just wanted you to confirm there
> wasn't anything I'm blatantly missing, thanks. The security check for
> the remoting call is still done, just not in the highest layer of the
> application. To prevent misuse, you could add IP or other additional
> security filters, I think that's clear. I'll remove the authc line,
> add some documentation for running the example and close this.
>
> Kalle
>
Re: svn commit: r911722 - in /incubator/shiro/trunk/samples/spring-client:
./ src/ src/main/ src/main/java/ src/main/java/org/ src/main/java/org/apache/
src/main/java/org/apache/shiro/ src/main/java/org/apache/shiro/samples/
src/main/java/org/apache/
Posted by Kalle Korhonen <ka...@gmail.com>.
On Mon, May 10, 2010 at 12:41 PM, Les Hazlewood <lh...@apache.org> wrote:
>>> I'll take a peek at the authentication issue. The idea was that you
>>> would authenticate via the webapp first (JSP) and then launch the
>>> webstart app. So, the /remoting/** = authc, ... line was added as an
>>> example of a secure app that can only be used if already
>>> authenticated. Does this make sense?
>>
>> Right, you can only launch the webstart app if you are logged in. But
>> the webstart app doesn't share the same session, or specifically,
>> doesn't carry the same session cookie in the http remote invocation
>> headers as the user's browser, so the request never reaches the
>> remoting servlet. Either there was some additional mechanism to deal
>> with that but it was lost along the way or I just don't understand how
>> this configuration could work. The SecureRemoteInvocationExecutor
>> itself does the expected thing, creating the subject from the session
>> id argument if the request is allowed to progress that far.
>
> Ah, I see now. I think having /remoting/** = authc doesn't make sense
> then. I think it probably makes more sense that a client should be
> able to execute a remote invocation at any point in the Subject's
> interaction with the system and rely on things like annotations or
> code checks to assert a user must be authenticated for a certain
> method.
> Then, if any filter would be applied to /remoting/** it would probably
> more likely be something like an SSL filter or IP filter to ensure the
> request is either secure, or comes from a certain IP or IP range or
> something like that.
> What do you think?
Right, that's how I figured it, just wanted you to confirm there
wasn't anything I'm blatantly missing, thanks. The security check for
the remoting call is still done, just not in the highest layer of the
application. To prevent misuse, you could add IP or other additional
security filters, I think that's clear. I'll remove the authc line,
add some documentation for running the example and close this.
Kalle
Re: svn commit: r911722 - in /incubator/shiro/trunk/samples/spring-client:
./ src/ src/main/ src/main/java/ src/main/java/org/ src/main/java/org/apache/
src/main/java/org/apache/shiro/ src/main/java/org/apache/shiro/samples/
src/main/java/org/apache/
Posted by Les Hazlewood <lh...@apache.org>.
>> I'll take a peek at the authentication issue. The idea was that you
>> would authenticate via the webapp first (JSP) and then launch the
>> webstart app. So, the /remoting/** = authc, ... line was added as an
>> example of a secure app that can only be used if already
>> authenticated. Does this make sense?
>
> Right, you can only launch the webstart app if you are logged in. But
> the webstart app doesn't share the same session, or specifically,
> doesn't carry the same session cookie in the http remote invocation
> headers as the user's browser, so the request never reaches the
> remoting servlet. Either there was some additional mechanism to deal
> with that but it was lost along the way or I just don't understand how
> this configuration could work. The SecureRemoteInvocationExecutor
> itself does the expected thing, creating the subject from the session
> id argument if the request is allowed to progress that far.
Ah, I see now. I think having /remoting/** = authc doesn't make sense
then. I think it probably makes more sense that a client should be
able to execute a remote invocation at any point in the Subject's
interaction with the system and rely on things like annotations or
code checks to assert a user must be authenticated for a certain
method.
Then, if any filter would be applied to /remoting/** it would probably
more likely be something like an SSL filter or IP filter to ensure the
request is either secure, or comes from a certain IP or IP range or
something like that.
What do you think?
- Les
Re: svn commit: r911722 - in /incubator/shiro/trunk/samples/spring-client:
./ src/ src/main/ src/main/java/ src/main/java/org/ src/main/java/org/apache/
src/main/java/org/apache/shiro/ src/main/java/org/apache/shiro/samples/
src/main/java/org/apache/
Posted by Kalle Korhonen <ka...@gmail.com>.
On Fri, Apr 2, 2010 at 10:09 AM, Les Hazlewood <lh...@apache.org> wrote:
> Actually there is a neat little trick about the system properties for
> JNLP apps: if you prefix the property with 'jnlp.' or 'javaws.', you
> can read the property without a security check. So something like
> 'jnlp.shiro.session.id' should work fine and then we'll save ourselves
> the jar signing time.
Yes, I know of the prefix. The Shiro code is not a problem anymore,
but it looked like it was some underlying code that was trying to read
the http.proxyHost or some such property (but a property that isn't
specifically sanctioned for sandbox mode) so I don't know if there's
an easy way to stop it from doing that.
> I'll take a peek at the authentication issue. The idea was that you
> would authenticate via the webapp first (JSP) and then launch the
> webstart app. So, the /remoting/** = authc, ... line was added as an
> example of a secure app that can only be used if already
> authenticated. Does this make sense?
Right, you can only launch the webstart app if you are logged in. But
the webstart app doesn't share the same session, or specifically,
doesn't carry the same session cookie in the http remote invocation
headers as the user's browser, so the request never reaches the
remoting servlet. Either there was some additional mechanism to deal
with that but it was lost along the way or I just don't understand how
this configuration could work. The SecureRemoteInvocationExecutor
itself does the expected thing, creating the subject from the session
id argument if the request is allowed to progress that far.
Kalle
> On Thu, Apr 1, 2010 at 5:01 PM, Kalle Korhonen
> <ka...@gmail.com> wrote:
>> On Fri, Mar 19, 2010 at 3:47 PM, Kalle Korhonen
>> <ka...@gmail.com> wrote:
>>> On Fri, Mar 19, 2010 at 3:19 PM, Les Hazlewood <lh...@apache.org> wrote:
>>>>> Well, actually the problem is not the jnlp file but
>>>>> SecureRemoteInvocationFactory itself as it tries to do
>>>>> System.getProperty(SESSION_ID_SYSTEM_PROPERTY_NAME) - are you
>>>> A probably sufficient solution would be to set a static property in
>>>> WebStartDriver's main method before instantiating the
>>>> ApplicationContext. Then you can reference that property from within
>>>> the Spring xml when defining the SecureRemoteInvocationFactory bean.
>>> Yeah, that's nice and simple - I'll get it implemented thanks! In
>>> fact, it would almost obsolete catching the exception, since it should
>>> likely prefer a session id that is explicitly set. Almost, not
>>> completely though - the code still would reach the part the gets it
>>> from the sessionid if the previous exception is caught and ignored.
>>
>> Ok, that was nice and simple but the underlying http transport code is
>> trying to read some other system property, so there's no easy way to
>> avoid signing the jars. However, I changed the implementation anyway
>> to use the argument and to inject the session id
>> SecureRemoveInvocationFactory as a constructor argument. I don't
>> really like the whole sessionid heuristic code but will do for now and
>> can be changed later without touching the interfaces. This is
>> committed. However, and I hate to dump this thing on you Les, but the
>> remaining issue is authenticating that http remote invocation call.
>> Currently it fails and redirects to the login page which obviously
>> throws an exception when remoting. So, the part I'm missing is how and
>> where is the authentication handled for the remoting requests.
>>
>> If you take out this line:
>> /remoting/** = authc, perms[remote:invoke]
>> from samples-spring/src/main/webapp/WEB-INF/applicationContext.xml,
>> starting the webstart app will succeed and generally works. Note that
>> if you run it in-place, you need use mvn jetty:run-exploded rather
>> than mvn jetty:run (because the build preps the target, rather than
>> the src directory with the webstart app).
>>
>> Kalle
>>
>
Re: svn commit: r911722 - in /incubator/shiro/trunk/samples/spring-client:
./ src/ src/main/ src/main/java/ src/main/java/org/ src/main/java/org/apache/
src/main/java/org/apache/shiro/ src/main/java/org/apache/shiro/samples/
src/main/java/org/apache/
Posted by Les Hazlewood <lh...@apache.org>.
Actually there is a neat little trick about the system properties for
JNLP apps: if you prefix the property with 'jnlp.' or 'javaws.', you
can read the property without a security check. So something like
'jnlp.shiro.session.id' should work fine and then we'll save ourselves
the jar signing time.
I'll take a peek at the authentication issue. The idea was that you
would authenticate via the webapp first (JSP) and then launch the
webstart app. So, the /remoting/** = authc, ... line was added as an
example of a secure app that can only be used if already
authenticated. Does this make sense?
Les
On Thu, Apr 1, 2010 at 5:01 PM, Kalle Korhonen
<ka...@gmail.com> wrote:
> On Fri, Mar 19, 2010 at 3:47 PM, Kalle Korhonen
> <ka...@gmail.com> wrote:
>> On Fri, Mar 19, 2010 at 3:19 PM, Les Hazlewood <lh...@apache.org> wrote:
>>>> Well, actually the problem is not the jnlp file but
>>>> SecureRemoteInvocationFactory itself as it tries to do
>>>> System.getProperty(SESSION_ID_SYSTEM_PROPERTY_NAME) - are you
>>> A probably sufficient solution would be to set a static property in
>>> WebStartDriver's main method before instantiating the
>>> ApplicationContext. Then you can reference that property from within
>>> the Spring xml when defining the SecureRemoteInvocationFactory bean.
>> Yeah, that's nice and simple - I'll get it implemented thanks! In
>> fact, it would almost obsolete catching the exception, since it should
>> likely prefer a session id that is explicitly set. Almost, not
>> completely though - the code still would reach the part the gets it
>> from the sessionid if the previous exception is caught and ignored.
>
> Ok, that was nice and simple but the underlying http transport code is
> trying to read some other system property, so there's no easy way to
> avoid signing the jars. However, I changed the implementation anyway
> to use the argument and to inject the session id
> SecureRemoveInvocationFactory as a constructor argument. I don't
> really like the whole sessionid heuristic code but will do for now and
> can be changed later without touching the interfaces. This is
> committed. However, and I hate to dump this thing on you Les, but the
> remaining issue is authenticating that http remote invocation call.
> Currently it fails and redirects to the login page which obviously
> throws an exception when remoting. So, the part I'm missing is how and
> where is the authentication handled for the remoting requests.
>
> If you take out this line:
> /remoting/** = authc, perms[remote:invoke]
> from samples-spring/src/main/webapp/WEB-INF/applicationContext.xml,
> starting the webstart app will succeed and generally works. Note that
> if you run it in-place, you need use mvn jetty:run-exploded rather
> than mvn jetty:run (because the build preps the target, rather than
> the src directory with the webstart app).
>
> Kalle
>
Re: svn commit: r911722 - in /incubator/shiro/trunk/samples/spring-client:
./ src/ src/main/ src/main/java/ src/main/java/org/ src/main/java/org/apache/
src/main/java/org/apache/shiro/ src/main/java/org/apache/shiro/samples/
src/main/java/org/apache/
Posted by Kalle Korhonen <ka...@gmail.com>.
On Fri, Mar 19, 2010 at 3:47 PM, Kalle Korhonen
<ka...@gmail.com> wrote:
> On Fri, Mar 19, 2010 at 3:19 PM, Les Hazlewood <lh...@apache.org> wrote:
>>> Well, actually the problem is not the jnlp file but
>>> SecureRemoteInvocationFactory itself as it tries to do
>>> System.getProperty(SESSION_ID_SYSTEM_PROPERTY_NAME) - are you
>> A probably sufficient solution would be to set a static property in
>> WebStartDriver's main method before instantiating the
>> ApplicationContext. Then you can reference that property from within
>> the Spring xml when defining the SecureRemoteInvocationFactory bean.
> Yeah, that's nice and simple - I'll get it implemented thanks! In
> fact, it would almost obsolete catching the exception, since it should
> likely prefer a session id that is explicitly set. Almost, not
> completely though - the code still would reach the part the gets it
> from the sessionid if the previous exception is caught and ignored.
Ok, that was nice and simple but the underlying http transport code is
trying to read some other system property, so there's no easy way to
avoid signing the jars. However, I changed the implementation anyway
to use the argument and to inject the session id
SecureRemoveInvocationFactory as a constructor argument. I don't
really like the whole sessionid heuristic code but will do for now and
can be changed later without touching the interfaces. This is
committed. However, and I hate to dump this thing on you Les, but the
remaining issue is authenticating that http remote invocation call.
Currently it fails and redirects to the login page which obviously
throws an exception when remoting. So, the part I'm missing is how and
where is the authentication handled for the remoting requests.
If you take out this line:
/remoting/** = authc, perms[remote:invoke]
from samples-spring/src/main/webapp/WEB-INF/applicationContext.xml,
starting the webstart app will succeed and generally works. Note that
if you run it in-place, you need use mvn jetty:run-exploded rather
than mvn jetty:run (because the build preps the target, rather than
the src directory with the webstart app).
Kalle
Re: svn commit: r911722 - in /incubator/shiro/trunk/samples/spring-client:
./ src/ src/main/ src/main/java/ src/main/java/org/ src/main/java/org/apache/
src/main/java/org/apache/shiro/ src/main/java/org/apache/shiro/samples/
src/main/java/org/apache/
Posted by Kalle Korhonen <ka...@gmail.com>.
On Fri, Mar 19, 2010 at 3:19 PM, Les Hazlewood <lh...@apache.org> wrote:
>> Well, actually the problem is not the jnlp file but
>> SecureRemoteInvocationFactory itself as it tries to do
>> System.getProperty(SESSION_ID_SYSTEM_PROPERTY_NAME) - are you
>> suggesting I change that whole approach to handle it differently?
> Ah, yes, I see the problem now. Yeah, we should probably find a
> different approach entirely, but I think the solution could be pretty
> simple:
> A probably sufficient solution would be to set a static property in
> WebStartDriver's main method before instantiating the
> ApplicationContext. Then you can reference that property from within
> the Spring xml when defining the SecureRemoteInvocationFactory bean.
Yeah, that's nice and simple - I'll get it implemented thanks! In
fact, it would almost obsolete catching the exception, since it should
likely prefer a session id that is explicitly set. Almost, not
completely though - the code still would reach the part the gets it
from the sessionid if the previous exception is caught and ignored.
Kalle
Re: svn commit: r911722 - in /incubator/shiro/trunk/samples/spring-client:
./ src/ src/main/ src/main/java/ src/main/java/org/ src/main/java/org/apache/
src/main/java/org/apache/shiro/ src/main/java/org/apache/shiro/samples/
src/main/java/org/apache/
Posted by Les Hazlewood <lh...@apache.org>.
On Fri, Mar 19, 2010 at 2:45 PM, Kalle Korhonen
<ka...@gmail.com> wrote:
> On Fri, Mar 19, 2010 at 2:10 PM, Les Hazlewood <lh...@apache.org> wrote:
>> On Fri, Mar 19, 2010 at 12:37 PM, Kalle Korhonen
>> <ka...@gmail.com> wrote:
>>> Very good. Yes, using the property was really the only reason why they
>>> needed to be signed. I'd rather not if that can be avoided. It's been
>>> awhile since I've last worked on webstart apps myself. I'll see if I
>>> can easily get it working by using an argument instead.
>> Cool. This should help:
>
> Well, actually the problem is not the jnlp file but
> SecureRemoteInvocationFactory itself as it tries to do
> System.getProperty(SESSION_ID_SYSTEM_PROPERTY_NAME) - are you
> suggesting I change that whole approach to handle it differently?
Ah, yes, I see the problem now. Yeah, we should probably find a
different approach entirely, but I think the solution could be pretty
simple:
A probably sufficient solution would be to set a static property in
WebStartDriver's main method before instantiating the
ApplicationContext. Then you can reference that property from within
the Spring xml when defining the SecureRemoteInvocationFactory bean.
Something like this:
<property name="sessionId">
<util:constant
static-field="org.apache.shiro.samples.spring.ui.WebStartDriver.LAUNCH_SESSION_ID"/>
</property>
Or whatever you want to call the static attribute...
Does that make sense?
- Les
Re: svn commit: r911722 - in /incubator/shiro/trunk/samples/spring-client:
./ src/ src/main/ src/main/java/ src/main/java/org/ src/main/java/org/apache/
src/main/java/org/apache/shiro/ src/main/java/org/apache/shiro/samples/
src/main/java/org/apache/
Posted by Kalle Korhonen <ka...@gmail.com>.
On Fri, Mar 19, 2010 at 2:10 PM, Les Hazlewood <lh...@apache.org> wrote:
> On Fri, Mar 19, 2010 at 12:37 PM, Kalle Korhonen
> <ka...@gmail.com> wrote:
>> Very good. Yes, using the property was really the only reason why they
>> needed to be signed. I'd rather not if that can be avoided. It's been
>> awhile since I've last worked on webstart apps myself. I'll see if I
>> can easily get it working by using an argument instead.
> Cool. This should help:
Well, actually the problem is not the jnlp file but
SecureRemoteInvocationFactory itself as it tries to do
System.getProperty(SESSION_ID_SYSTEM_PROPERTY_NAME) - are you
suggesting I change that whole approach to handle it differently?
> Yeah, I agree - I guess I was thinking more along the lines of
> extended integration across multiple technologies in addition to
> samples - kind of like why wicket-stuff exists. It is also
> interesting that their project exists outside of Apache so the
> community can write samples and integration code for whatever they
> want, even if it's not Apache compatible (GPL, LGPL, etc). Something
> to think about if the community finds a need for something like this.
Yeah, but Shiro being a fairly-well established security project,
other projects hosted elsewhere are already integrating our stuff so I
don't think we need to host everything-and-the-kitchen-sink
integration projects as part of Shiro. But on case by case by I
suppose - we'll do one if we need one.
Kalle
Re: svn commit: r911722 - in /incubator/shiro/trunk/samples/spring-client:
./ src/ src/main/ src/main/java/ src/main/java/org/ src/main/java/org/apache/
src/main/java/org/apache/shiro/ src/main/java/org/apache/shiro/samples/
src/main/java/org/apache/
Posted by Les Hazlewood <lh...@apache.org>.
On Fri, Mar 19, 2010 at 12:37 PM, Kalle Korhonen
<ka...@gmail.com> wrote:
> On Tue, Mar 16, 2010 at 2:28 PM, Les Hazlewood <lh...@apache.org> wrote:
>> I don't like catching an exception much either, but I think the
>> isSecurityManagerAvailable() method might cause us problems -
>> SecurityUtils is a very public-facing API and having that method might
>> confuse people - in most cases, a SecurityManager should always be
>> available. That one wouldn't be available is a client-tier-only very
>> special case.
>> Maybe catching the exception for now is ok until after 1.0? Maybe we
>> can deal with it a little cleaner after the release?
>
> Agree, that's the practical solution for now. It's only in the support
> module so it's not hugely critical.
Agreed.
>> Also, if we change the JNLP file from using properties to using
>> arguments (<argument>...), we won't need to sign the .jars at all.
>> That should be ok.
>
> Very good. Yes, using the property was really the only reason why they
> needed to be signed. I'd rather not if that can be avoided. It's been
> awhile since I've last worked on webstart apps myself. I'll see if I
> can easily get it working by using an argument instead.
Cool. This should help:
http://java.sun.com/javase/6/docs/technotes/guides/javaws/developersguide/syntax.html#application_desc
>> Another idea is, once we become a top-level project is to maybe move
>> all of the samples to a samples/recipes project? Kind of like
>> Wicket's wicket-stuff project or similar?
>
> Making it an independently releasable module serves the same purpose
> with less overhead. I'd only make it sub-project if there were
> sufficient number of people interested in working only on that
> sub-project. For a sample, I don't see it happening.
Yeah, I agree - I guess I was thinking more along the lines of
extended integration across multiple technologies in addition to
samples - kind of like why wicket-stuff exists. It is also
interesting that their project exists outside of Apache so the
community can write samples and integration code for whatever they
want, even if it's not Apache compatible (GPL, LGPL, etc). Something
to think about if the community finds a need for something like this.
Cheers,
Les
Re: svn commit: r911722 - in /incubator/shiro/trunk/samples/spring-client:
./ src/ src/main/ src/main/java/ src/main/java/org/ src/main/java/org/apache/
src/main/java/org/apache/shiro/ src/main/java/org/apache/shiro/samples/
src/main/java/org/apache/
Posted by Kalle Korhonen <ka...@gmail.com>.
On Tue, Mar 16, 2010 at 2:28 PM, Les Hazlewood <lh...@apache.org> wrote:
> I don't like catching an exception much either, but I think the
> isSecurityManagerAvailable() method might cause us problems -
> SecurityUtils is a very public-facing API and having that method might
> confuse people - in most cases, a SecurityManager should always be
> available. That one wouldn't be available is a client-tier-only very
> special case.
> Maybe catching the exception for now is ok until after 1.0? Maybe we
> can deal with it a little cleaner after the release?
Agree, that's the practical solution for now. It's only in the support
module so it's not hugely critical.
> I think the build process signed the .jars but wasn't run as part of
> the normal development build cycle. I think we called a specific ant
> target at the time. (kind of like using a Maven profile).
Figured we could do that, but the example wouldn't really be usable
without signing them. Profiles are a good tool in your toolbox, but
from my experience the use of profiles should be as limited as
possible.
> I agree - it'd be nice to move anything that might delay the 1.0
> release that isn't critical or a bug to be dealt with afterwards.
> Also, if we change the JNLP file from using properties to using
> arguments (<argument>...), we won't need to sign the .jars at all.
> That should be ok.
Very good. Yes, using the property was really the only reason why they
needed to be signed. I'd rather not if that can be avoided. It's been
awhile since I've last worked on webstart apps myself. I'll see if I
can easily get it working by using an argument instead.
> Another idea is, once we become a top-level project is to maybe move
> all of the samples to a samples/recipes project? Kind of like
> Wicket's wicket-stuff project or similar?
Making it an independently releasable module serves the same purpose
with less overhead. I'd only make it sub-project if there were
sufficient number of people interested in working only on that
sub-project. For a sample, I don't see it happening.
Kalle
Re: svn commit: r911722 - in /incubator/shiro/trunk/samples/spring-client:
./ src/ src/main/ src/main/java/ src/main/java/org/ src/main/java/org/apache/
src/main/java/org/apache/shiro/ src/main/java/org/apache/shiro/samples/
src/main/java/org/apache/
Posted by Les Hazlewood <lh...@apache.org>.
>> My opinion is that we allow a SecurityManager instance to be injected
>> and we can use that if it exists. If not, we try
>> SecurityUtils.getSecurityManager (it can be the case in a single-user
>> standalone application to make a client-side SecurityManager proxy
>> accessible via a static reference). But if that method throws an
>> exception (which should be a changed to a type-safe exception, like
>> UnavailableSecurityManagerException), we just ignore it for the
>> remoting factory and assume there isn't one. In that case, the
>
> Yes, with that change it'll work. Still, I don't really like the idea
> that you have to catch an exception and then ignore it when you know
> it doesn't have to be there. Of course, we could add one more
> operation such SecurityUtils.isSecurityManagerAvailable() but I'm not
> sure if adding more code is the right way to solve it. What do you
> think? Regardless, SecureRemoteInvocationFactory needs to handle the
> case one way or another.
I don't like catching an exception much either, but I think the
isSecurityManagerAvailable() method might cause us problems -
SecurityUtils is a very public-facing API and having that method might
confuse people - in most cases, a SecurityManager should always be
available. That one wouldn't be available is a client-tier-only very
special case.
Maybe catching the exception for now is ok until after 1.0? Maybe we
can deal with it a little cleaner after the release?
> So, with that change (still uncommitted but I'm simply catching and
> ignoring the exception now in my local copy of Shiro support) I can
> almost get the webstart to work. This might deserve a whole separate
> thread but if you've been watching recent commits, I've automated the
> whole sample with Maven. It's turning to be more of an exercise to use
> Maven rather than a demonstration of secure remoting capabilitites.
> From the commit logs, it seems that the sample had been broken for
> quite some time, possibly for a couple of years. I'm sure previously
> it simply had the libs manually signed and checked in.
I think the build process signed the .jars but wasn't run as part of
the normal development build cycle. I think we called a specific ant
target at the time. (kind of like using a Maven profile).
> Now, the build
> collects the dependencies, signs them, generates the JNLP file and
> zips it up ready to consumed by the spring web application. This whole
> thing comes at a high cost though:
> [INFO] Apache Shiro :: Samples :: Spring Client .............. SUCCESS
> [1:38.361s]
> [INFO] BUILD SUCCESSFUL
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 4 minutes 34 seconds
>
> Signing the jars for webstart takes quite a bit of time. Signing is
> required since SecureRemoteInvocationFactory calls
> System.getProperty(SESSION_ID_SYSTEM_PROPERTY_NAME) which is not
> permitted in the unsecured sandbox mode. One option is to move the
> samples-spring-client to the root level and make it an independently
> releasable module, but the problem is that somebody still needs to
> build it or it needs to be used as a released dependency (but that
> also requires it uses only released dependencies, and there are none
> available it could use right now). I'd suggest we suffer through until
> 1.0.0 release, then change it so.
I agree - it'd be nice to move anything that might delay the 1.0
release that isn't critical or a bug to be dealt with afterwards.
Also, if we change the JNLP file from using properties to using
arguments (<argument>...), we won't need to sign the .jars at all.
That should be ok.
> A totally different option is to
> evaluate the need for the whole sample and eliminate it if it's not
> useful to anybody (I'm big on eliminating stale code :) ). If we are
> not running and maintaining the sample, it doesn't deserve to exist.
> I'm not really suggesting removing it - I think it does showcase
> Shiro's flexibility rather well - but just saying that we need to
> understand the maintenance costs if we want to keep it around.
I'd be happy maintaining this, but when we made the switch to Maven,
it was never high priority for me to figure out to make it play nice
w/ the Maven build. Now that you have helped out with this (thanks!),
I'm happy with maintaining the code again if no one else wants to. I
might have some reasons in the coming months for showing this work in
various client environments ;)
Another idea is, once we become a top-level project is to maybe move
all of the samples to a samples/recipes project? Kind of like
Wicket's wicket-stuff project or similar?
Cheers,
Les
Re: svn commit: r911722 - in /incubator/shiro/trunk/samples/spring-client:
./ src/ src/main/ src/main/java/ src/main/java/org/ src/main/java/org/apache/
src/main/java/org/apache/shiro/ src/main/java/org/apache/shiro/samples/
src/main/java/org/apache/
Posted by Kalle Korhonen <ka...@gmail.com>.
On Mon, Feb 22, 2010 at 6:59 AM, Les Hazlewood
<le...@anjinllc.com> wrote:
> On Sat, Feb 20, 2010 at 4:47 AM, Kalle Korhonen
> Here is a little back story on how/why the
> SecureRemoteInvocationFactory works the way it does:
> It primarily existed to support remote client applications that were
> started/launched after a server-side session had been created first
> (think login HTTPs page --> success --> launch/show app). Then the
Right, that's sort of what I gathered from the source.
> My opinion is that we allow a SecurityManager instance to be injected
> and we can use that if it exists. If not, we try
> SecurityUtils.getSecurityManager (it can be the case in a single-user
> standalone application to make a client-side SecurityManager proxy
> accessible via a static reference). But if that method throws an
> exception (which should be a changed to a type-safe exception, like
> UnavailableSecurityManagerException), we just ignore it for the
> remoting factory and assume there isn't one. In that case, the
Yes, with that change it'll work. Still, I don't really like the idea
that you have to catch an exception and then ignore it when you know
it doesn't have to be there. Of course, we could add one more
operation such SecurityUtils.isSecurityManagerAvailable() but I'm not
sure if adding more code is the right way to solve it. What do you
think? Regardless, SecureRemoteInvocationFactory needs to handle the
case one way or another.
So, with that change (still uncommitted but I'm simply catching and
ignoring the exception now in my local copy of Shiro support) I can
almost get the webstart to work. This might deserve a whole separate
thread but if you've been watching recent commits, I've automated the
whole sample with Maven. It's turning to be more of an exercise to use
Maven rather than a demonstration of secure remoting capabilitites.
>From the commit logs, it seems that the sample had been broken for
quite some time, possibly for a couple of years. I'm sure previously
it simply had the libs manually signed and checked in. Now, the build
collects the dependencies, signs them, generates the JNLP file and
zips it up ready to consumed by the spring web application. This whole
thing comes at a high cost though:
[INFO] Apache Shiro :: Samples :: Spring Client .............. SUCCESS
[1:38.361s]
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 4 minutes 34 seconds
Signing the jars for webstart takes quite a bit of time. Signing is
required since SecureRemoteInvocationFactory calls
System.getProperty(SESSION_ID_SYSTEM_PROPERTY_NAME) which is not
permitted in the unsecured sandbox mode. One option is to move the
samples-spring-client to the root level and make it an independently
releasable module, but the problem is that somebody still needs to
build it or it needs to be used as a released dependency (but that
also requires it uses only released dependencies, and there are none
available it could use right now). I'd suggest we suffer through until
1.0.0 release, then change it so. A totally different option is to
evaluate the need for the whole sample and eliminate it if it's not
useful to anybody (I'm big on eliminating stale code :) ). If we are
not running and maintaining the sample, it doesn't deserve to exist.
I'm not really suggesting removing it - I think it does showcase
Shiro's flexibility rather well - but just saying that we need to
understand the maintenance costs if we want to keep it around.
Kalle
Re: svn commit: r911722 - in /incubator/shiro/trunk/samples/spring-client:
./ src/ src/main/ src/main/java/ src/main/java/org/ src/main/java/org/apache/
src/main/java/org/apache/shiro/ src/main/java/org/apache/shiro/samples/
src/main/java/org/apache/
Posted by Les Hazlewood <le...@anjinllc.com>.
On Sat, Feb 20, 2010 at 4:47 AM, Kalle Korhonen
<ka...@gmail.com> wrote:
> I think we need to do three things:
> 1) Decide what is the contract for the Subject.Builder - is it allowed
> to fail or should it always return a subject
The initial idea at least was that it should always return a valid
subject assuming it has access to a SecurityManager. The
Subject.Builder is just an abstraction so people don't have to know
how to populate the Subject context Map themselves.
This implies that a Subject.Builder should always have a reference to
a valid SecurityManager instance - either via SecurityUtils or one
that is provided explicitly
(Subject.Builder(securityManager).blah().blah()...)
> 2) Break the circular dependency between SecurityUtils.getSubject ->
> Subject.Builder.buildSubject() -> SecurityUtils.getSecurityManager().
> I think SecurityUtils is nothing more than a convenience and
> internally, we need to be careful about *not* using it.
The difficulty here is that the client tier could have a reference to
a SecurityManager remoting proxy - I've done this in more than a few
client-tier standalone apps. In this case, the 2nd 'if block' in the
SecureRemoteInvocationFactory at line 80 would utilize the
Subject.Builder which would in turn use the client-tier
SecurityManager proxy.
Maybe if a client-side SecurityManager proxy existed, it could be
injected into the Factory, and if so, use it with the Builder in the
line 80 code block? And if there isn't one provided, try
SecurityUtils.getSecurityManager, but if it throws an exception,
ignore it assuming that the client tier doesn't have one?
Here is a little back story on how/why the
SecureRemoteInvocationFactory works the way it does:
It primarily existed to support remote client applications that were
started/launched after a server-side session had been created first
(think login HTTPs page --> success --> launch/show app). Then the
client tier app would have in its start-up parameters that sessionId
(Flex app, Java Web Start, etc) which would be attached to the
remoting payload for every remote call to ensure that the server would
always know who that user was.
This implied that the client tier might not use Shiro's APIs directly
- Subject/SecurityManager/etc, which is a real possibility for clients
based on languages not yet supported by Shiro (PHP, C#, etc) or even
simpler Java applications that don't want to (or can't for reasons out
of our control) utilize Shiro's API. They could just send the
sessionId only. In these no-Shiro-API clients, they would perform
permission checks to show buttons/views or not based on a call to say,
a SubjectService, implying remote invocations to check the user's
access control.
> 3) Add unit tests to SecureRemoteInvocationFactory to cover all cases
> for heuristics
I agree - we have a SecureRemoteInvocationFactoryTest class already,
but it does need to updated after we decide exactly how this should
operate moving forward.
My opinion is that we allow a SecurityManager instance to be injected
and we can use that if it exists. If not, we try
SecurityUtils.getSecurityManager (it can be the case in a single-user
standalone application to make a client-side SecurityManager proxy
accessible via a static reference). But if that method throws an
exception (which should be a changed to a type-safe exception, like
UnavailableSecurityManagerException), we just ignore it for the
remoting factory and assume there isn't one. In that case, the
sessionId is checked as a last resort, and if it doesn't exist, then
the server invocation will be anonymous, at which point the
server-side Shiro mechanisms might prevent the invocation completely.
> Note that the current sample that's
> committed isn't runnable at the moment (the webstart libs are not
> copied to the right location and the jnlp lib entries are wrong,
> etc.).
Yep, that is the reason for the issue initially - it wouldn't start
because it doesn't have a valid classpath.
What do you think of my potential solution after #3 above? It seems
fairly robust.
Cheers,
Les
Re: svn commit: r911722 - in /incubator/shiro/trunk/samples/spring-client:
./ src/ src/main/ src/main/java/ src/main/java/org/ src/main/java/org/apache/
src/main/java/org/apache/shiro/ src/main/java/org/apache/shiro/samples/
src/main/java/org/apache/
Posted by Kalle Korhonen <ka...@gmail.com>.
Spent a bit more time on this. The issue in this specific case is line
81 of SecureRemoteInvocationFactory.createRemoteInvocation where
SecurityUtils.getSubject(); is called. This fails on
IllegalStateException when the Subject.Builder tries to obtain the
SecurityManager from SecurityUtils (but it doesn't need to be set at
all on the client side). The heuristics to obtain the sessionid from
the systemproperty (a bit later in createRemoteInvocation) is never
given a chance to work. We could probably fix that in
SecureRemoteInvocationFactory, but the way this is written makes me
suspect that SecurityUtils.getSubject() was previously not allowed to
fail and didn't throw exceptions which likely explains other similar
failure cases users have recently reported.
I think we need to do three things:
1) Decide what is the contract for the Subject.Builder - is it allowed
to fail or should it always return a subject
2) Break the circular dependency between SecurityUtils.getSubject ->
Subject.Builder.buildSubject() -> SecurityUtils.getSecurityManager().
I think SecurityUtils is nothing more than a convenience and
internally, we need to be careful about *not* using it.
3) Add unit tests to SecureRemoteInvocationFactory to cover all cases
for heuristics
Once we resolve these, fixing the Spring sample shouldn't be too
difficult. Les, you probably need to work on some of the above items
or at least give your input. Note that the current sample that's
committed isn't runnable at the moment (the webstart libs are not
copied to the right location and the jnlp lib entries are wrong,
etc.).
Kalle
On Fri, Feb 19, 2010 at 1:49 PM, Les Hazlewood <lh...@apache.org> wrote:
> Ah, ok - I'll check that out this weekend and hopefully find out 1)
> why and 2) come up with a clear way to try and make sure it won't
> happen regularly.
>
> On Fri, Feb 19, 2010 at 4:21 PM, Kalle Korhonen
> <ka...@gmail.com> wrote:
>> Yeah, you are overthinking it :) That's exactly the same thought I
>> had, but then I simply decided we can always move it around later if
>> and when users get confused about it. Why do it right away, the cost
>> of doing it later is no bigger than it is today.
>>
>> Anyway, I'm at the point with it where I can log in and start up the
>> Webstart client but it fails on "No SecurityManager accessible to the
>> calling code..." when its trying to initialize WebStartView and
>> calling SecurityUtils.getSubject() as part of the process. I do find
>> it ironic that I'm tripping over the same code that quite a few users
>> have complained about (I think there's even a user thread exactly on
>> this topic when using Spring standalone sample). So while I do know
>> what that the problem is (that the SecurityManager is not set either
>> as static property of SecurityUtils or in the thread context) I'm not
>> absolutely sure what and where is the SecurityManager supposed to be
>> set in this environment.
>>
>> Kalle
>>
>>
>> On Fri, Feb 19, 2010 at 11:12 AM, Les Hazlewood <lh...@apache.org> wrote:
>>> My concern was that people would probably look at each peer directory
>>> in the examples project as a self-contained runnable application and
>>> could be really confused as to how the webstart one would work. Maybe
>>> not though - maybe I'm just thinking about it too much :)
>>>
>>> On Fri, Feb 19, 2010 at 1:28 PM, Kalle Korhonen
>>> <ka...@gmail.com> wrote:
>>>> I considered that but didn't see it as too beneficial to make the
>>>> module hierarchy deeper. We would need to introduce a new parent pom
>>>> for spring module and put both the war and the jar modules underneath.
>>>> However, we only need the war to package it up as it'll contain the
>>>> jar module. Sure, spring-client cannot be run as a standalone sample
>>>> but I don't think it should be too confusing. If we prefer to move it
>>>> to it's own multi-module build we can do that later.
>>>>
>>>> Kalle
>>>>
>>>>
>>>> On Fri, Feb 19, 2010 at 10:07 AM, Les Hazlewood <lh...@apache.org> wrote:
>>>>> I just realized that this module is a peer to the spring webapp that
>>>>> launches it via webstart. Shouldn't it be a module underneath a web
>>>>> project since it can't reside on its own without the webapp? Just
>>>>> trying to understand the reasoning...
>>>>>
>>>>> On Fri, Feb 19, 2010 at 9:21 AM, Les Hazlewood <lh...@apache.org> wrote:
>>>>>> This is awesome, thanks!
>>>>>>
>>>>>> On Fri, Feb 19, 2010 at 2:25 AM, <ka...@apache.org> wrote:
>>>>>>> Author: kaosko
>>>>>>> Date: Fri Feb 19 07:25:50 2010
>>>>>>> New Revision: 911722
>>>>>>>
>>>>>>> URL: http://svn.apache.org/viewvc?rev=911722&view=rev
>>>>>>> Log:
>>>>>>> SHIRO-89: Sample Spring Application - WebStart won't launch
>>>>>>> - Refactor Spring sample client from Spring sample into its own module to make packaging & dependency management easier and simpler. Work in progress
>>>>>>>
>>>>>>> Added:
>>>>>>> incubator/shiro/trunk/samples/spring-client/
>>>>>
>>>>
>>>
>>
>
Re: svn commit: r911722 - in /incubator/shiro/trunk/samples/spring-client:
./ src/ src/main/ src/main/java/ src/main/java/org/ src/main/java/org/apache/
src/main/java/org/apache/shiro/ src/main/java/org/apache/shiro/samples/
src/main/java/org/apache/
Posted by Les Hazlewood <lh...@apache.org>.
Ah, ok - I'll check that out this weekend and hopefully find out 1)
why and 2) come up with a clear way to try and make sure it won't
happen regularly.
On Fri, Feb 19, 2010 at 4:21 PM, Kalle Korhonen
<ka...@gmail.com> wrote:
> Yeah, you are overthinking it :) That's exactly the same thought I
> had, but then I simply decided we can always move it around later if
> and when users get confused about it. Why do it right away, the cost
> of doing it later is no bigger than it is today.
>
> Anyway, I'm at the point with it where I can log in and start up the
> Webstart client but it fails on "No SecurityManager accessible to the
> calling code..." when its trying to initialize WebStartView and
> calling SecurityUtils.getSubject() as part of the process. I do find
> it ironic that I'm tripping over the same code that quite a few users
> have complained about (I think there's even a user thread exactly on
> this topic when using Spring standalone sample). So while I do know
> what that the problem is (that the SecurityManager is not set either
> as static property of SecurityUtils or in the thread context) I'm not
> absolutely sure what and where is the SecurityManager supposed to be
> set in this environment.
>
> Kalle
>
>
> On Fri, Feb 19, 2010 at 11:12 AM, Les Hazlewood <lh...@apache.org> wrote:
>> My concern was that people would probably look at each peer directory
>> in the examples project as a self-contained runnable application and
>> could be really confused as to how the webstart one would work. Maybe
>> not though - maybe I'm just thinking about it too much :)
>>
>> On Fri, Feb 19, 2010 at 1:28 PM, Kalle Korhonen
>> <ka...@gmail.com> wrote:
>>> I considered that but didn't see it as too beneficial to make the
>>> module hierarchy deeper. We would need to introduce a new parent pom
>>> for spring module and put both the war and the jar modules underneath.
>>> However, we only need the war to package it up as it'll contain the
>>> jar module. Sure, spring-client cannot be run as a standalone sample
>>> but I don't think it should be too confusing. If we prefer to move it
>>> to it's own multi-module build we can do that later.
>>>
>>> Kalle
>>>
>>>
>>> On Fri, Feb 19, 2010 at 10:07 AM, Les Hazlewood <lh...@apache.org> wrote:
>>>> I just realized that this module is a peer to the spring webapp that
>>>> launches it via webstart. Shouldn't it be a module underneath a web
>>>> project since it can't reside on its own without the webapp? Just
>>>> trying to understand the reasoning...
>>>>
>>>> On Fri, Feb 19, 2010 at 9:21 AM, Les Hazlewood <lh...@apache.org> wrote:
>>>>> This is awesome, thanks!
>>>>>
>>>>> On Fri, Feb 19, 2010 at 2:25 AM, <ka...@apache.org> wrote:
>>>>>> Author: kaosko
>>>>>> Date: Fri Feb 19 07:25:50 2010
>>>>>> New Revision: 911722
>>>>>>
>>>>>> URL: http://svn.apache.org/viewvc?rev=911722&view=rev
>>>>>> Log:
>>>>>> SHIRO-89: Sample Spring Application - WebStart won't launch
>>>>>> - Refactor Spring sample client from Spring sample into its own module to make packaging & dependency management easier and simpler. Work in progress
>>>>>>
>>>>>> Added:
>>>>>> incubator/shiro/trunk/samples/spring-client/
>>>>
>>>
>>
>
Re: svn commit: r911722 - in /incubator/shiro/trunk/samples/spring-client:
./ src/ src/main/ src/main/java/ src/main/java/org/ src/main/java/org/apache/
src/main/java/org/apache/shiro/ src/main/java/org/apache/shiro/samples/
src/main/java/org/apache/
Posted by Kalle Korhonen <ka...@gmail.com>.
Yeah, you are overthinking it :) That's exactly the same thought I
had, but then I simply decided we can always move it around later if
and when users get confused about it. Why do it right away, the cost
of doing it later is no bigger than it is today.
Anyway, I'm at the point with it where I can log in and start up the
Webstart client but it fails on "No SecurityManager accessible to the
calling code..." when its trying to initialize WebStartView and
calling SecurityUtils.getSubject() as part of the process. I do find
it ironic that I'm tripping over the same code that quite a few users
have complained about (I think there's even a user thread exactly on
this topic when using Spring standalone sample). So while I do know
what that the problem is (that the SecurityManager is not set either
as static property of SecurityUtils or in the thread context) I'm not
absolutely sure what and where is the SecurityManager supposed to be
set in this environment.
Kalle
On Fri, Feb 19, 2010 at 11:12 AM, Les Hazlewood <lh...@apache.org> wrote:
> My concern was that people would probably look at each peer directory
> in the examples project as a self-contained runnable application and
> could be really confused as to how the webstart one would work. Maybe
> not though - maybe I'm just thinking about it too much :)
>
> On Fri, Feb 19, 2010 at 1:28 PM, Kalle Korhonen
> <ka...@gmail.com> wrote:
>> I considered that but didn't see it as too beneficial to make the
>> module hierarchy deeper. We would need to introduce a new parent pom
>> for spring module and put both the war and the jar modules underneath.
>> However, we only need the war to package it up as it'll contain the
>> jar module. Sure, spring-client cannot be run as a standalone sample
>> but I don't think it should be too confusing. If we prefer to move it
>> to it's own multi-module build we can do that later.
>>
>> Kalle
>>
>>
>> On Fri, Feb 19, 2010 at 10:07 AM, Les Hazlewood <lh...@apache.org> wrote:
>>> I just realized that this module is a peer to the spring webapp that
>>> launches it via webstart. Shouldn't it be a module underneath a web
>>> project since it can't reside on its own without the webapp? Just
>>> trying to understand the reasoning...
>>>
>>> On Fri, Feb 19, 2010 at 9:21 AM, Les Hazlewood <lh...@apache.org> wrote:
>>>> This is awesome, thanks!
>>>>
>>>> On Fri, Feb 19, 2010 at 2:25 AM, <ka...@apache.org> wrote:
>>>>> Author: kaosko
>>>>> Date: Fri Feb 19 07:25:50 2010
>>>>> New Revision: 911722
>>>>>
>>>>> URL: http://svn.apache.org/viewvc?rev=911722&view=rev
>>>>> Log:
>>>>> SHIRO-89: Sample Spring Application - WebStart won't launch
>>>>> - Refactor Spring sample client from Spring sample into its own module to make packaging & dependency management easier and simpler. Work in progress
>>>>>
>>>>> Added:
>>>>> incubator/shiro/trunk/samples/spring-client/
>>>
>>
>
Re: svn commit: r911722 - in /incubator/shiro/trunk/samples/spring-client:
./ src/ src/main/ src/main/java/ src/main/java/org/ src/main/java/org/apache/
src/main/java/org/apache/shiro/ src/main/java/org/apache/shiro/samples/
src/main/java/org/apache/
Posted by Les Hazlewood <lh...@apache.org>.
My concern was that people would probably look at each peer directory
in the examples project as a self-contained runnable application and
could be really confused as to how the webstart one would work. Maybe
not though - maybe I'm just thinking about it too much :)
On Fri, Feb 19, 2010 at 1:28 PM, Kalle Korhonen
<ka...@gmail.com> wrote:
> I considered that but didn't see it as too beneficial to make the
> module hierarchy deeper. We would need to introduce a new parent pom
> for spring module and put both the war and the jar modules underneath.
> However, we only need the war to package it up as it'll contain the
> jar module. Sure, spring-client cannot be run as a standalone sample
> but I don't think it should be too confusing. If we prefer to move it
> to it's own multi-module build we can do that later.
>
> Kalle
>
>
> On Fri, Feb 19, 2010 at 10:07 AM, Les Hazlewood <lh...@apache.org> wrote:
>> I just realized that this module is a peer to the spring webapp that
>> launches it via webstart. Shouldn't it be a module underneath a web
>> project since it can't reside on its own without the webapp? Just
>> trying to understand the reasoning...
>>
>> On Fri, Feb 19, 2010 at 9:21 AM, Les Hazlewood <lh...@apache.org> wrote:
>>> This is awesome, thanks!
>>>
>>> On Fri, Feb 19, 2010 at 2:25 AM, <ka...@apache.org> wrote:
>>>> Author: kaosko
>>>> Date: Fri Feb 19 07:25:50 2010
>>>> New Revision: 911722
>>>>
>>>> URL: http://svn.apache.org/viewvc?rev=911722&view=rev
>>>> Log:
>>>> SHIRO-89: Sample Spring Application - WebStart won't launch
>>>> - Refactor Spring sample client from Spring sample into its own module to make packaging & dependency management easier and simpler. Work in progress
>>>>
>>>> Added:
>>>> incubator/shiro/trunk/samples/spring-client/
>>
>
Re: svn commit: r911722 - in /incubator/shiro/trunk/samples/spring-client:
./ src/ src/main/ src/main/java/ src/main/java/org/ src/main/java/org/apache/
src/main/java/org/apache/shiro/ src/main/java/org/apache/shiro/samples/
src/main/java/org/apache/
Posted by Kalle Korhonen <ka...@gmail.com>.
I considered that but didn't see it as too beneficial to make the
module hierarchy deeper. We would need to introduce a new parent pom
for spring module and put both the war and the jar modules underneath.
However, we only need the war to package it up as it'll contain the
jar module. Sure, spring-client cannot be run as a standalone sample
but I don't think it should be too confusing. If we prefer to move it
to it's own multi-module build we can do that later.
Kalle
On Fri, Feb 19, 2010 at 10:07 AM, Les Hazlewood <lh...@apache.org> wrote:
> I just realized that this module is a peer to the spring webapp that
> launches it via webstart. Shouldn't it be a module underneath a web
> project since it can't reside on its own without the webapp? Just
> trying to understand the reasoning...
>
> On Fri, Feb 19, 2010 at 9:21 AM, Les Hazlewood <lh...@apache.org> wrote:
>> This is awesome, thanks!
>>
>> On Fri, Feb 19, 2010 at 2:25 AM, <ka...@apache.org> wrote:
>>> Author: kaosko
>>> Date: Fri Feb 19 07:25:50 2010
>>> New Revision: 911722
>>>
>>> URL: http://svn.apache.org/viewvc?rev=911722&view=rev
>>> Log:
>>> SHIRO-89: Sample Spring Application - WebStart won't launch
>>> - Refactor Spring sample client from Spring sample into its own module to make packaging & dependency management easier and simpler. Work in progress
>>>
>>> Added:
>>> incubator/shiro/trunk/samples/spring-client/
>
Re: svn commit: r911722 - in /incubator/shiro/trunk/samples/spring-client:
./ src/ src/main/ src/main/java/ src/main/java/org/ src/main/java/org/apache/
src/main/java/org/apache/shiro/ src/main/java/org/apache/shiro/samples/
src/main/java/org/apache/
Posted by Les Hazlewood <lh...@apache.org>.
I just realized that this module is a peer to the spring webapp that
launches it via webstart. Shouldn't it be a module underneath a web
project since it can't reside on its own without the webapp? Just
trying to understand the reasoning...
On Fri, Feb 19, 2010 at 9:21 AM, Les Hazlewood <lh...@apache.org> wrote:
> This is awesome, thanks!
>
> On Fri, Feb 19, 2010 at 2:25 AM, <ka...@apache.org> wrote:
>> Author: kaosko
>> Date: Fri Feb 19 07:25:50 2010
>> New Revision: 911722
>>
>> URL: http://svn.apache.org/viewvc?rev=911722&view=rev
>> Log:
>> SHIRO-89: Sample Spring Application - WebStart won't launch
>> - Refactor Spring sample client from Spring sample into its own module to make packaging & dependency management easier and simpler. Work in progress
>>
>> Added:
>> incubator/shiro/trunk/samples/spring-client/