views:

82

answers:

1

I am trying and understand the next steps I have to take starting from the reference application at

http://svn.codehaus.org/spring-security-oauth/trunk/sparklr/

in order to create my own implementation. What I do not understand is where and how to declare dynamic resources for Oauth. In the reference app, resources are hard coded within the xml config:

   <bean id="photoServices" class="org.springframework.security.oauth.examples.sparklr.impl.PhotoServiceImpl">
    <property name="photos">
        <list>
            <bean class="org.springframework.security.oauth.examples.sparklr.PhotoInfo">
                <property name="id" value="1"/>
                <property name="name" value="photo1.jpg"/>
                <property name="userId" value="marissa"/>
                <property name="resourceURL"
                          value="/org/springframework/security/oauth/examples/sparklr/impl/resources/photo1.jpg"/>
            </bean>
            <bean class="org.springframework.security.oauth.examples.sparklr.PhotoInfo">
                <property name="id" value="2"/>
                <property name="name" value="photo2.jpg"/>
                <property name="userId" value="paul"/>
                <property name="resourceURL"
                          value="/org/springframework/security/oauth/examples/sparklr/impl/resources/photo2.jpg"/>
            </bean>
             <!-- some more -->
        </list>
    </property>
   </bean>

I guess, this is no way to handle resources created by the users in the real world. So: How is this supposed to be done?

A: 

In the example shown above, it looks like the beans are pre-configured at design time and pre-loaded by Spring.

Did you consider actually creating and loading the beans dynamically during runtime?

This way, you can access the "photos" list whenever a new dynamic resource is created and add it directly to the list "photos"?

Sarat
Hi Sarat. Yes, the resources are created dynamically at runtime. Thus, I do not know their names. I want to make the access to the resources dependent on the *username*.
The only way (theoretically) I can see this working is if you create your own authentication filter which uses the OAuth API and grabs the logged in principal to effectively perform custom authentication. Obviously, it's easier said that done!
Sarat
Obviously, yes. Thanks anyway