Quantcast

[ANN] Multi Tenant Single DB 0.8.2 Release

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[ANN] Multi Tenant Single DB 0.8.2 Release

Steve Ronderos-2
Hello Community,

I'm pleased to announce the 0.8.2 release of the multi-tenant-single-db plugin!

This release contains a few bug fixes, Grails 2.0.0 compatibility as well as a new script for integrating with Spring Security.

Let us know if you have any questions or concerns about the release.

Thanks!
Steve
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [ANN] Multi Tenant Single DB 0.8.2 Release

Kimble
Thanks a lot for your time!
 - Kim A. Betti
Have a nice day!
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [ANN] Multi Tenant Single DB 0.8.2 Release

Jonathan Andrew Ong
Hi,

Is there any documentation on how / what it does? 

Thanks!

On Tue, Feb 21, 2012 at 11:27 PM, Kimble <[hidden email]> wrote:
Thanks a lot for your time!

-----
 - Kim A. Betti
Have a nice day!
--
View this message in context: http://grails.1312388.n4.nabble.com/ANN-Multi-Tenant-Single-DB-0-8-2-Release-tp4407248p4407324.html
Sent from the Grails - user mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [ANN] Multi Tenant Single DB 0.8.2 Release

Kimble
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [ANN] Multi Tenant Single DB 0.8.2 Release

lucastex
In reply to this post by Steve Ronderos-2
Yeah!

Thanks for publishing it Steve!

[]s,

On Tuesday, February 21, 2012, Steve Ronderos wrote:
Hello Community,

I'm pleased to announce the 0.8.2 release of the multi-tenant-single-db plugin!

This release contains a few bug fixes, Grails 2.0.0 compatibility as well as a new script for integrating with Spring Security.

Let us know if you have any questions or concerns about the release.

Thanks!
Steve


--

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [ANN] Multi Tenant Single DB 0.8.2 Release

Graeme Rocher-2
Nice! Great work.

-- 
Graeme Rocher
Sent with Sparrow

On Tuesday, February 21, 2012 at 7:44 PM, Lucas F. A. Teixeira wrote:

Yeah!

Thanks for publishing it Steve!

[]s,

On Tuesday, February 21, 2012, Steve Ronderos wrote:
Hello Community,

I'm pleased to announce the 0.8.2 release of the multi-tenant-single-db plugin!

This release contains a few bug fixes, Grails 2.0.0 compatibility as well as a new script for integrating with Spring Security.

Let us know if you have any questions or concerns about the release.

Thanks!
Steve


--


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [ANN] Multi Tenant Single DB 0.8.2 Release

OverZealous
In reply to this post by Steve Ronderos-2
Great!  This is an awesome plugin.

Any notes for upgrading from 0.8.1 to 0.8.2?

- Phil DeJarnett

Steve Ronderos wrote:
Hello Community,

I'm pleased to announce the 0.8.2 release of the multi-tenant-single-db plugin!

This release contains a few bug fixes, Grails 2.0.0 compatibility as well as a new script for integrating with Spring Security.

Let us know if you have any questions or concerns about the release.

Thanks!
Steve
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [ANN] Multi Tenant Single DB 0.8.2 Release

OverZealous
I'm experiencing a NoCurrentTenantException after upgrading.  I've tried downgrading to 0.8.1 and it works again.

The exception occurs when saving the PersistentLoginToken in Spring Security Core.  It logs in correctly (meaning it finds the user and validates), but then it fails when saving the token.

My TenantResolver *always* returns a tenant ID.  It's got a fallback to an "Default Company" that is used when the domain (URL) is unknown.

Plugins:
fields 1.0.4            --  Fields Plugin
hawk-eventing 0.5.1            --  Hawk Eventing
hibernate 2.0.1            --  Hibernate for Grails
hibernate-hijacker 0.8.1            --  Hibernate Hijacker
jquery 1.7.1            --  JQuery for Grails
mail 1.0               --  Provides Mail support to a running Grails application
multi-tenant-single-db 0.8.2            --  MultiTenant - SingleDB
resources 1.1.6            --  Resources
spring-security-core 1.2.7.2         --  Spring Security Core Plugin
svn 1.0.0.M1     --  Subversion Plugin
tomcat 2.0.1            --  Apache Tomcat plugin for Grails
webxml 1.4.1            --  WebXmlConfig

I attached the key parts of the stacktrace.

Any idea what might have changed?

- Phil DeJarnett




stacktrace.log (10K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [ANN] Multi Tenant Single DB 0.8.2 Release

OverZealous
Phil DeJarnett wrote:
The exception occurs when saving the PersistentLoginToken in Spring Security Core.  It logs in correctly (meaning it finds the user and validates), but then it fails when saving the token.

I forgot to mention that I have annotated PersistentLoginToken with MultiTenant to ensure that persistent tokens are attached to the tenant.

- Phil DeJarnett



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [ANN] Multi Tenant Single DB 0.8.2 Release

OverZealous
OK, I've definitely narrowed it down.  The error is no longer thrown if I comment out this block in MultiTenantSingleDbGrailsPlugin.groovy:

    // make sure the filter chain filter is after the Grails filter
    def getWebXmlFilterOrder() {
    def FilterManager = getClass().getClassLoader().loadClass('grails.plugin.webxml.FilterManager')
    [tenantFilter: FilterManager.SITEMESH_POSITION - 100]
    }

Is there some reason why forcing the filter to the end would cause it to no longer determine the tenant based on code like this:

Integer resolve(HttpServletRequest request) throws TenantResolveException {
String subdomain = extractSubdomain(request.getServerName())

def id = null

if(subdomain) {
id = Company.findBySubdomain(subdomain)?.id
}

id ?: DEFAULT_TENANT_ID
}

(extractSubdomain is just a regex, DEFAULT_TENANT_ID is a static property set during BootStrap to ensure that there's always some tenant.)

I'd love to upgrade, but this is a real issue.


- Phil DeJarnett




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [ANN] Multi Tenant Single DB 0.8.2 Release

Steve Ronderos-2
Hi Phil,

Sorry I didn't get back to you sooner.

You are correct that the problem is in the order of the CurrentTenantServletFilter and the Spring Security Filters.

Because your Spring Security classes are annotated with @MultiTenant that means you will need the CurrentTenantServletFilter to run before the Spring Security filters to ensure that the tenant is set when the Spring Security filters go asking for it.  

The default order of the filters (using the getWebXmlFilterOrder()) has the tenantFilter positioned after the Spring Security filter.  It is this way to support users who determine tenant by User and not the other way around.

I'm not exactly sure how to change the filter order, it is something that I need to look into. I believe you should be able to customize the order using the webxml plugin.

One final thought.  Do you need to annotate the PersistentUserToken?  I'm not very familiar with that feature of Spring Security, but it seems like the token is keyed off of the User.  I can't tell from this post, or the other where we discussed your use case if you need the PersistentLoginToken to be annotated with @MultiTenant.

I'll get back to you about the webxml plugin.  Could you post some more information about how you want to use Spring Security Core and Multi Tenant Single DB together?  

Thanks,
Steve


On Tue, Feb 21, 2012 at 11:44 PM, Phil DeJarnett <[hidden email]> wrote:
OK, I've definitely narrowed it down.  The error is no longer thrown if I comment out this block in MultiTenantSingleDbGrailsPlugin.groovy:

    // make sure the filter chain filter is after the Grails filter
    def getWebXmlFilterOrder() {
    def FilterManager = getClass().getClassLoader().loadClass('grails.plugin.webxml.FilterManager')
    [tenantFilter: FilterManager.SITEMESH_POSITION - 100]
    }

Is there some reason why forcing the filter to the end would cause it to no longer determine the tenant based on code like this:

Integer resolve(HttpServletRequest request) throws TenantResolveException {
String subdomain = extractSubdomain(request.getServerName())

def id = null

if(subdomain) {
id = Company.findBySubdomain(subdomain)?.id
}

id ?: DEFAULT_TENANT_ID
}

(extractSubdomain is just a regex, DEFAULT_TENANT_ID is a static property set during BootStrap to ensure that there's always some tenant.)

I'd love to upgrade, but this is a real issue.


- Phil DeJarnett





Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [ANN] Multi Tenant Single DB 0.8.2 Release

OverZealous
Steve Ronderos wrote:
One final thought.  Do you need to annotate the PersistentUserToken?  I'm not very familiar with that feature of Spring Security, but it seems like the token is keyed off of the User.  I can't tell from this post, or the other where we discussed your use case if you need the PersistentLoginToken to be annotated with @MultiTenant.

I think this is important.  I want to make sure someone can't copy the Persistent User Token to a different subdomain (see below) and use it to get logged in under a different tenant.  I haven't done a ton of thinking into this, but it made sense to me.

PeristentLoginToken is not actually related to User directly.  Instead, the username is stored with the token.  (I don't actually like that, but whatever... it works.)  Without digging into how the token is used to authenticate the user, I figured it was best to tie the tokens to the tenant.

I'll get back to you about the webxml plugin.  Could you post some more information about how you want to use Spring Security Core and Multi Tenant Single DB together?  

Sure.

What I've done is created a Company class that is my tenant.  The current tenant is determined by the subdomain exclusively.  If the current subdomain is not in the database, it defaults to a generic tenant (one without users, etc.)

Each tenant has multiple users, which are Spring security users.  I've annotated User and (as of now) PersistentLoginToken.  (The other Spring security classes are shared across tenants.)

Even though I'm using the user's email for the username, I actually don't want to prevent the same email address from being used on multiple tenants (at least, for now).  This makes some other things easier, like dealing with self-registration.  Currently, a user can only log in if they are visiting the correct tenant URL.

Thanks for your help,
- Phil DeJarnett
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [ANN] Multi Tenant Single DB 0.8.2 Release

Steve Ronderos-2
Hi Phil,

It sounds like you have two criteria for tenants. Proper sub domain and matching user. I'd recommend adding the user match to your tenant resolver to prevent the user crossing domains. This would remove the need for annotating the PersistentUserToken

Do you think that would work?
Steve

On Feb 22, 2012, at 10:30 AM, Phil DeJarnett <[hidden email]> wrote:

Steve Ronderos wrote:
One final thought.  Do you need to annotate the PersistentUserToken?  I'm not very familiar with that feature of Spring Security, but it seems like the token is keyed off of the User.  I can't tell from this post, or the other where we discussed your use case if you need the PersistentLoginToken to be annotated with @MultiTenant.

I think this is important.  I want to make sure someone can't copy the Persistent User Token to a different subdomain (see below) and use it to get logged in under a different tenant.  I haven't done a ton of thinking into this, but it made sense to me.

PeristentLoginToken is not actually related to User directly.  Instead, the username is stored with the token.  (I don't actually like that, but whatever... it works.)  Without digging into how the token is used to authenticate the user, I figured it was best to tie the tokens to the tenant.

I'll get back to you about the webxml plugin.  Could you post some more information about how you want to use Spring Security Core and Multi Tenant Single DB together?  

Sure.

What I've done is created a Company class that is my tenant.  The current tenant is determined by the subdomain exclusively.  If the current subdomain is not in the database, it defaults to a generic tenant (one without users, etc.)

Each tenant has multiple users, which are Spring security users.  I've annotated User and (as of now) PersistentLoginToken.  (The other Spring security classes are shared across tenants.)

Even though I'm using the user's email for the username, I actually don't want to prevent the same email address from being used on multiple tenants (at least, for now).  This makes some other things easier, like dealing with self-registration.  Currently, a user can only log in if they are visiting the correct tenant URL.

Thanks for your help,
- Phil DeJarnett
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [ANN] Multi Tenant Single DB 0.8.2 Release

OverZealous
Steve Ronderos wrote:
It sounds like you have two criteria for tenants. Proper sub domain and matching user. I'd recommend adding the user match to your tenant resolver to prevent the user crossing domains. This would remove the need for annotating the PersistentUserToken

Do you think that would work?

I'll look into it and let you know.  I'm not actually 100% it's even necessary to secure the PersistentUserToken (and I'm not sure how I would go about testing it).  I was already planning on throwing in a hook to log out the user if they don't match the tenant.

- Phil DeJarnett
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [ANN] Multi Tenant Single DB 0.8.2 Release

OverZealous
Phil DeJarnett wrote:
Steve Ronderos wrote:
It sounds like you have two criteria for tenants. Proper sub domain and matching user. I'd recommend adding the user match to your tenant resolver to prevent the user crossing domains. This would remove the need for annotating the PersistentUserToken

Do you think that would work?

I'll look into it and let you know.  I'm not actually 100% it's even necessary to secure the PersistentUserToken (and I'm not sure how I would go about testing it).  I was already planning on throwing in a hook to log out the user if they don't match the tenant.

So, here's where I am with this:

I went through and modified my DomainTenantResolver to throw an error if the current user's tenant is wrong.  This works well (I think).  I was able to take the @MultiTenant annotation off the PersistentLoginToken domain class.

However, by doing this, the User domain class, while marked as MultiTenant, is not checked when logging in.  This is because, as before, the SpringSecurity filters are happening before the MultiTenant ones, and therefore the login check apparently is ignoring the tenantId.  I've tried hacking it into a custom UserDetailsService, but there is just no way to determine the tenant ID while looking up the user (all of the spring injections are turning up null).

I could just use the solution provided by mt-spring-security, but I lose the ability to use the domain name as the tenant resolver, which I liked.

I'll keep researching for a better solution.

- Phil




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [ANN] Multi Tenant Single DB 0.8.2 Release

OverZealous
Phil DeJarnett wrote:
I'll keep researching for a better solution.

OK, here's what I came up with.  It's not the prettiest, but it does exactly what I want:

In my custom UserDetailsService, I injected my domain-based tenantResolver.  Then, I looked up the current tenant using:

    tenantResolver.resolve(GrailsWebRequest.lookup().currentRequest)

Then, if there is a current tenantId, I changed my lookup to be findbyUsernameAndTenantId(username, tenantId).

This forces the user login to be bound by the current tenant.  It's a little more hand-holding than I'd like, but it was pretty easy to get working, and it's a one-time fix.

I modified tenantResolver to handle the case where currentRequest is null, just in case.  It also throws an error if the current user doesn't have the correct tenantId (which is unlikely to happen, but a good safety check).  I don't like this, though, because it's then impossible for the user to actually log out.  I might replace this with a forced logout through spring security.

Overall it seems to be holding up well as of right now.

- Phil DeJarnett




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [ANN] Multi Tenant Single DB 0.8.2 Release

Steve Ronderos-2
Hi Phil,

Glad to hear that you got it working!  Someone else was asking about annotating the User class in Spring Security. Glad you got it figured out.

-Steve


On Feb 23, 2012, at 1:40 AM, Phil DeJarnett <[hidden email]> wrote:

Phil DeJarnett wrote:
I'll keep researching for a better solution.

OK, here's what I came up with.  It's not the prettiest, but it does exactly what I want:

In my custom UserDetailsService, I injected my domain-based tenantResolver.  Then, I looked up the current tenant using:

    tenantResolver.resolve(GrailsWebRequest.lookup().currentRequest)

Then, if there is a current tenantId, I changed my lookup to be findbyUsernameAndTenantId(username, tenantId).

This forces the user login to be bound by the current tenant.  It's a little more hand-holding than I'd like, but it was pretty easy to get working, and it's a one-time fix.

I modified tenantResolver to handle the case where currentRequest is null, just in case.  It also throws an error if the current user doesn't have the correct tenantId (which is unlikely to happen, but a good safety check).  I don't like this, though, because it's then impossible for the user to actually log out.  I might replace this with a forced logout through spring security.

Overall it seems to be holding up well as of right now.

- Phil DeJarnett




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [ANN] Multi Tenant Single DB 0.8.2 Release

alxndrsn
In reply to this post by OverZealous
On 23 February 2012 10:40, Phil DeJarnett <[hidden email]> wrote:
> In my custom UserDetailsService, I injected my domain-based tenantResolver.
> Then, I looked up the current tenant using:

I've been trying to follow this approach, but my tenantResolver is not
being injected into my custom userDetailsService.  I've declared `def
tenantResolver` at the top of the class, and tried explicitly
specifying it via `ref()` in `resources.groovy` - am I missing
something?

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [ANN] Multi Tenant Single DB 0.8.2 Release

alxndrsn
On 10 October 2012 18:30, Alex Anderson
<[hidden email]> wrote:
> On 23 February 2012 10:40, Phil DeJarnett <[hidden email]> wrote:
>> In my custom UserDetailsService, I injected my domain-based tenantResolver.
>> Then, I looked up the current tenant using:
>
> I've been trying to follow this approach, but my tenantResolver is not
> being injected into my custom userDetailsService.  I've declared `def
> tenantResolver` at the top of the class, and tried explicitly
> specifying it via `ref()` in `resources.groovy` - am I missing
> something?

Ignore that - works fine today.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Loading...