2011-03-30 15 views

Respuesta

16

Shiro no requieren tablas de base de datos para funcionar. Shiro usuarios pueden usar cualquier almacén de datos que quieren modelar o es propietario de usuarios, grupos, permisos etc.

Es un Realm Shiro 's responsabilidad de actuar como puente a sus datos (como quiera que la represente) y devolverlo en un formato que Shiro entiende.

Dado que Shiro no impone un modelo de datos sobre usted, esto es lo que le permite trabajar con tantos backends (LDAP, Active Directory, RDBMS, Sistema de archivos, etc.).

Si desea utilizar un RDBMS como su almacén de datos de respaldo, consulte el código fuente JdbcRealm de Shiro para que tenga una idea de cómo se verían sus tablas. Esto es solo un ejemplo. Podrías tener cualquier estructura de tabla que desees.

+0

Esta respuesta parece correcta, pero no responde la pregunta. Por ejemplo, un conjunto de declaraciones de creación sería una mejor respuesta. –

2

Una desnatada de Shiro quick startup page y Realm documentation page no trae nada sobre MySQL o bases de datos en absoluto. Basado en eso, no parece que ninguna tabla en particular sea requerida.

+0

Las tablas se deben crear de alguna manera. –

6

según tengo entendido, solo requiere 3 tengo 3 tablas y 2 vistas que utilizo como fuente de datos para el marco. tengo esto en un Postgresql, pero puede adaptarlo para usar en otros dbs.

probar esto

CREATE SCHEMA app; 

CREATE TABLE app.sec_permissions ( 
    permission_id int4 NOT NULL, 
    permission_name varchar(64) NOT NULL, 
    role_id int4 NOT NULL, 
CONSTRAINT pk_sec_permissions PRIMARY KEY (permission_id), 
CONSTRAINT idx_sec_permissions_unq_name UNIQUE (permission_name) 
); 

CREATE INDEX idx_sec_permissions ON app.sec_permissions (role_id); 

CREATE TABLE app.sec_roles ( 
    role_id int4 NOT NULL, 
    role_name varchar(32) NOT NULL, 
    user_id int4 NOT NULL, 
CONSTRAINT pk_sec_roles_0 PRIMARY KEY (role_id), 
CONSTRAINT idx_sec_roles_unq_name UNIQUE (role_name) 
); 

CREATE INDEX idx_sec_roles ON app.sec_roles (user_id); 

CREATE TABLE app.sec_users ( 
    user_id int4 NOT NULL, 
    user_loginname varchar(32) NOT NULL, 
    user_password varchar(254) NOT NULL, 
    user_passsalt varchar(254) NOT NULL, 
CONSTRAINT pk_sec_users PRIMARY KEY (user_id), 
CONSTRAINT idx_sec_users_unq_loginname UNIQUE (user_loginname) 
) 
; 

ALTER TABLE app.sec_permissions ADD CONSTRAINT fk_sec_permissions FOREIGN KEY (role_id) REFERENCES app.sec_roles(role_id) ON DELETE CASCADE ON UPDATE CASCADE 
; 

ALTER TABLE app.sec_roles ADD CONSTRAINT fk_sec_roles FOREIGN KEY (user_id) REFERENCES app.sec_users(user_id) ON DELETE CASCADE ON UPDATE CASCADE 
; 

CREATE VIEW app.sec_loginname_roles AS SELECT 
    su.user_loginname 
, su.user_password 
, su.user_passsalt 
, sr.role_name 

FROM 
app.sec_users su 
    INNER JOIN app.sec_roles sr 
    ON 
      (su.user_id = sr.user_id ); 

CREATE VIEW app.sec_role_permissions AS SELECT sr.role_name, sp.permission_name 
FROM app.sec_roles sr 
    INNER JOIN app.sec_permissions sp ON (sr.role_id = sp.role_id ); 

si encuentra algo mal, por favor mensaje Volver

Cuestiones relacionadas