Time |
S |
Nick |
Message |
00:20 |
|
|
Mugave joined ##javaee |
00:20 |
|
Mugave |
~help |
00:20 |
|
Mugave |
!help |
00:42 |
|
pdurbin |
@help |
00:42 |
|
crimsonfubot |
pdurbin: (help [<plugin>] [<command>]) -- This command gives a useful description of what <command> does. <plugin> is only necessary if the command is in more than one plugin. |
01:41 |
|
Naros |
Mugave: yes? |
01:56 |
|
|
pcuser joined ##javaee |
01:56 |
|
pcuser |
Hello |
01:57 |
|
pcuser |
I am trying to teach myself java in my spare time, and i'm having some difficulty. I am using intellij on xubuntu. I am trying to add an external library to my project, i compiled the library using maven, and copied it into my lib/ dir, right clicked it and selected 'add as library' |
01:58 |
|
pcuser |
when i write the import statements, the library shows up on the auto-complete thing, but when i goto compile and run the program, i get the error "java: package com.turn.ttorrent does not exist" |
01:59 |
|
pcuser |
im not sure what i'm doing wrong |
02:00 |
|
pdurbin |
you'd think if autocomplete worked that it would find it during compilation, but I've never used intellij (thought everyone raves about it). should "just work" in netbeans |
02:01 |
|
pdurbin |
(especially if you create a maven project in netbeans) |
02:02 |
|
pcuser |
my main reason for learning java is to develop android app's and android studio is based on intellij i think, anyway i realised i needed to learn regular java before i could make progress with android app's, so i chose intellij so i had a similar interface & environment for my java based stuff |
02:02 |
|
pcuser |
i do like netbeans though |
02:03 |
|
pdurbin |
ah. yeah, i've been meaning to download android studio |
02:05 |
|
pdurbin |
pcuser: you could try to get it working outside an IDE first. :) |
02:07 |
|
pcuser |
using a text editor & cli? no thanks :) i see your point, but working with an IDE is always more productive in my experience. |
02:08 |
|
pcuser |
i've just created a new empty project, tried to import the library again and same problem. at least now i know it wasn't something my last project that was messing it up |
02:09 |
|
pdurbin |
pcuser: maybe you should try cloning a project with a dependency on an external library from github |
02:14 |
|
pdurbin |
to see a working example |
03:16 |
|
|
kobain joined ##javaee |
03:37 |
|
|
Quest joined ##javaee |
04:42 |
|
|
raoul- joined ##javaee |
05:14 |
|
|
ThisMoment joined ##javaee |
05:16 |
|
* Quest |
ThisMoment nice nick |
05:17 |
|
ThisMoment |
:D |
05:22 |
|
Quest |
:) |
05:33 |
|
xll11 |
Naros / sfisque yeah, QA is a good entry point.. havne't thought of it |
05:34 |
|
xll11 |
I like to code, I do it in my spare time without regards to school assignments etc, but I have no idea whats the work like in the 'industry' |
05:35 |
|
Quest |
xll11, how old are you and what are your embitions? |
05:40 |
|
Quest |
xll11, participate in an opensource project? |
05:41 |
|
xll11 |
24 and I want to accumulate as much knowledge as possible |
05:41 |
|
xll11 |
that seems like a good idea, where do I find opensource projects I can contribute to? |
05:44 |
|
Quest |
sure |
05:44 |
|
Quest |
ofcourse- |
05:45 |
|
* Quest |
recommends google and github |
06:26 |
|
xll11 |
I'll do that |
06:26 |
|
xll11 |
I think my next project will be java irc client |
06:27 |
|
Quest |
good. |
06:29 |
|
|
d joined ##javaee |
06:37 |
|
Quest |
xll11, if you can tell me you profile? |
06:37 |
|
Quest |
I might guide you better |
07:15 |
|
|
dinesh___ joined ##javaee |
07:15 |
|
|
dinesh___ left ##javaee |
07:39 |
|
|
Maziz joined ##javaee |
08:56 |
|
xll11 |
Oh damn he left |
08:56 |
|
xll11 |
I wasn't around |
08:56 |
|
xll11 |
What he means by my propfile tho? and wha you guys think, should I start a github from now? to 'showcase' my code etC? |
10:43 |
|
pdurbin |
xll11: he probably means your github username |
12:35 |
|
javanewb |
any decent company you interview with is going to look to see if and what you have on Github |
13:14 |
|
|
phao joined ##javaee |
13:14 |
|
|
phao left ##javaee |
13:25 |
|
|
Quest joined ##javaee |
13:25 |
|
|
Naros_ joined ##javaee |
13:26 |
|
Guest77 |
xll11, soryy, i was disconnected last time we were talking |
13:42 |
|
|
Maziz joined ##javaee |
13:56 |
|
|
kobain joined ##javaee |
15:08 |
|
|
sl33k joined ##javaee |
15:39 |
|
|
neuro_sys joined ##javaee |
16:54 |
|
|
joshua_jandyco joined ##javaee |
17:20 |
|
javanewb |
so quiet |
17:21 |
|
sfisque |
yah. it's like the tide. comes and goes |
17:24 |
|
javanewb |
the mud is starting to get cracks |
17:29 |
|
Naros_ |
sorry ive been hiding in #hibernate lately :P |
17:30 |
|
Naros |
Quest: do you want to discuss your stack post here or in pm? |
17:35 |
|
javanewb |
why not here? others may benefit |
17:35 |
|
Naros |
I dont mind here, up to Quest. |
17:36 |
|
Naros |
Altho he seems afk :P |
17:36 |
|
javanewb |
busy man |
17:36 |
|
Naros |
know the feeling :3 |
17:49 |
|
Quest |
Naros, hi |
17:50 |
|
Quest |
I was away. back now. I dont mind either place |
17:50 |
|
Naros |
Ok, lets do it here in case others have input or want to know |
17:50 |
|
* Quest |
agrees with javanewb |
17:50 |
|
Quest |
for reference. the stack post ishttp://stackoverflow.com/questions/17793414/spring-3-hibernate-4-user-authentication-and-privileges |
17:51 |
|
javanewb |
unclickable link |
17:51 |
|
Naros |
Alright, lets cover some basics. |
17:51 |
|
Naros |
Most security frameworks provide you with some core features |
17:51 |
|
Naros |
(1) maintain a session with a principal context of the user who is authenticated |
17:51 |
|
Naros |
(2) maintain context data for what URIs are possible versus not possible for a principal |
17:52 |
|
Naros |
(3) provide ability to filter method calls using the principal |
17:52 |
|
Naros |
A principal can be anything, but generally is some User session object that contains loaded data at authentication time. |
17:53 |
|
Naros |
So my suggestion to you was to look at Spring Security since you were already using Spring. |
17:53 |
|
Quest |
hm |
17:53 |
|
javanewb |
your code shouldn't have to deal with security |
17:53 |
|
Naros |
SSEC has remember-me support and various authentication options it supports, including Active Directory, LDAP, or even custom providers. |
17:54 |
|
Naros |
javanewb: depends |
17:54 |
|
Naros |
He wants to know where to interact with the security |
17:54 |
|
Quest |
hm.. |
17:54 |
|
Naros |
Typically business methods in services are where security interaction is done |
17:54 |
|
Quest |
Naros, is there a working example on the web, or I am using incorrect keywords? |
17:55 |
|
javanewb |
Naros: right which is typically at the container level |
17:55 |
|
Naros |
Agreed. |
17:55 |
|
Naros |
Now you can get SSEC to work on an entity-by-entity basis but that depends on the project |
17:55 |
|
Naros |
I didn't want to maintain a security record for every entity in my ERP system :/ |
17:56 |
|
Naros |
So I created a custom permission evaluator system per module that has business rules |
17:56 |
|
sfisque |
security needs to be top to bottom, especially if you're exposing functionality via non "web" endpoints (message bus, REST, RMI/CORBA, etc.) |
17:56 |
|
Naros |
and that evaluator interacts with the standard @PreAuthorize, @PostAuthorize, @PostFilter annotations |
17:57 |
|
Naros |
sfisque: correct and since the medium could be different, the best place for this is at the business method level or service level. |
17:57 |
|
Naros |
Quest: working examples, probably but like anything else this type of stuff varies from project to project |
17:57 |
|
sfisque |
negative. so you're saying the deep layers have to respond in ways that the UI understands? |
17:58 |
|
sfisque |
there are different aspects to authorization other than just "can i execute method X" |
17:58 |
|
Naros |
sfisque: no. I have a a service that returns a list of entities. I don't care if the client is a webapp or a GUI. the list of returned objects should be consistent and permissions validated the same, regardless of the client. |
17:58 |
|
sfisque |
some are definitely the perview of the controller/view. some are not and need to be deep |
17:59 |
|
Naros |
There are corner cases that I agree, may existing higher up the chain in the controller/view, yes. |
17:59 |
|
Naros |
But I prefer to avoid security in the controller/view |
17:59 |
|
sfisque |
right but from a UX standpoint, i shouldnt expose functionality that will "fail". thus the view/controller needs a way to say, "can she execute X" without having to actually execute and fail |
17:59 |
|
sfisque |
not corner cases, very real durable cases |
18:00 |
|
sfisque |
i just listed one |
18:00 |
|
sfisque |
from a business standpoint "execute and fail" is not a valid workflow from UX standpoint |
18:01 |
|
Naros |
Even if you're using @PreAuthorize that doesn't actually execute the method unless validation succeeds? |
18:02 |
|
sfisque |
just because it's being intercepted, it's still execute/fail. |
18:02 |
|
sfisque |
the user clikced a button they should not ahve been able to click |
18:02 |
|
sfisque |
or expanded a tab that should not have been shown to them |
18:03 |
|
Naros |
Right, but nothing stops user from fudging with the URL to bypass UI restrictions etiehr. |
18:03 |
|
sfisque |
of course, you need BOTH |
18:03 |
|
sfisque |
or all three |
18:03 |
|
Naros |
Exactly. |
18:03 |
|
sfisque |
or X, depending on the granularity |
18:04 |
|
sfisque |
i'm just saying you can't ignore one or the other. too many times one gets ignored, and then you end up with a system where one layer has good authorization, and the other one is "square peg" bolted on |
18:04 |
|
Naros |
So Quest - where to apply these restrictions varies. I chose to do it at the service tier myself and fail but sfisque has a different approach that is just as valid. |
18:05 |
|
Naros |
Doing this at the DAO level is definitely bad. |
18:05 |
|
Naros |
DAO should be able to reading/writing data to whatever the datastore is imo. |
18:05 |
|
|
dreamreal joined ##javaee |
18:05 |
|
sfisque |
aye. you always need to secure the services because any good hacker will completely ignore your UI and go right for the exposure points. but you still need a good authorization model at the controller/view tier so the user has a clean/valid UX |
18:05 |
|
sfisque |
only if the DAO layer is completely blunted from the outside |
18:05 |
|
Naros |
Definitely. |
18:06 |
|
sfisque |
if any of those methods are accessible via remote APIs, they need to enforce AA as well |
18:06 |
|
sfisque |
consider two web apps in the same container using methods shared via @Remote |
18:07 |
|
Naros |
So Quest |
18:07 |
|
Naros |
security frameworks often handle #1 transparently for you |
18:07 |
|
Naros |
they know if the user is logged in or not and if they aren't, can redirect to some login page for you |
18:08 |
|
Naros |
during authentication, they typically have some hook mechanism or override logic where you can fetch your own permissions from a datastore to fit your needs. |
18:08 |
|
Naros |
we use a complex role, authorization object like setup here that mimics SAP |
18:09 |
|
Naros |
we just feed into the authorization list all the authorization objects based on the roles a user is associated to and all the permissions that go along with that |
18:09 |
|
Naros |
then during URI invocation, we validate the permissions with what the user is trying to do and fail if they're not permitted. |
18:10 |
|
Naros |
that catches the cases where users are doing things they shouldn't. As sfisque pointed out, you shoudl have other logic in place that prevents those features being made available to the user via the UI. |
18:10 |
|
Naros |
I generally put all this in the controller with an extra security check at the services. |
18:11 |
|
Quest |
a minute only. brb |
18:11 |
|
Naros |
k |
18:11 |
|
Quest |
boss |
18:12 |
|
Naros |
Spring security does come with a taglib that can help you too with the view part or you can do controller checks to set variables that you expose to the jsp and control what is made visible through those controller variables. |
18:14 |
|
Naros |
in my experience, I prefer the latter because my own checks have often been very complex and the taglib isn't so great with very complex cases. If your security cases are very simple, cut-n-dry, then perhaps it's the way to go. |
18:14 |
|
sfisque |
aye, even though i'm not a great fan of spring, spring sec is decently laid out |
18:14 |
|
Naros |
Indeed. |
18:14 |
|
Naros |
We've used it for a number of years and haven't been disappointed by it at all. It's very extendable too |
18:15 |
|
Naros |
We like the idea of being able to validate users from their own corporate ldap, our own active directory, and to fall back to local DB authentication in the two prior fail for users :) |
18:15 |
|
Naros |
Since our app is integrated with local, corporate, and client user bases. |
18:16 |
|
Naros |
think the setup for that was only like 50 lines of code or somesuch :P |
18:16 |
|
Naros |
most being configs |
18:19 |
|
Naros |
Anywho, my last comment is related to your exception handling. I can't speak for Spring's web framework since we use Struts2, but I would suspect you could just catch the AccessDeniedException that SSEC throws and redirect the user to whatever page you wanted. Depending on the input request type, AJAX requests respond with JSON responses and non-AJAX requests are coded to redirect the user to a simple access denied page that gives them an expl |
18:21 |
|
Naros |
sfisque: the permissions evaluator I spoke of earlier. we actually use that in combination with AspectJ to set attributes on our entities that are security related. |
18:21 |
|
Naros |
then we use the entity model as a means to enable/disable UI aspects |
18:22 |
|
Naros |
entity.isSomeSpecialFeatureAllowed() |
18:23 |
|
Naros |
our decision to do this was because entity's facility might be id 1 which for the user context would allow some special feature but for entities where facility id is 2, that feature isn't possible. The evaluator centralizes all this logic |
18:23 |
|
sfisque |
nifty |
18:24 |
|
Naros |
Yep, allowed us to return collections of entities, filter them and set those attributes too |
18:24 |
|
Naros |
anyone here used Byteman? |
18:37 |
|
Naros |
off to lunch, be back in an hour or so. |
19:17 |
|
Quest |
Naros, all of the permission and credential matching is on the database. and some are just booleans (very very custom database queries for which i may need seperate daos/services). sfisque what do you mean dao layer should be blunted? |
19:18 |
|
Naros |
Quest: I personally dislike real time queries for permissions if I can avoid it. Security permissions generally are static enough that query once at login, store them and just use the session stored values for evaluation purposes. |
19:19 |
|
Quest |
Naros, I meant hibernate machnism == queries. bad implication though |
19:19 |
|
Naros |
But yes, you'd need a set of DAO/Services perhaps to acquire those, even at login. |
19:19 |
|
Naros |
Your queries join permission tables? |
19:20 |
|
Quest |
Naros, but I may have to do new queries on each act of a user |
19:20 |
|
Naros |
But why would you need to query the database for each action? |
19:21 |
|
Quest |
Naros, to elaborate users table > user-permision table (is creater , is inviter, is moderator) . acts based on those booleans |
19:21 |
|
Quest |
many users, many acts, many times |
19:21 |
|
Quest |
have to do all that on runtime |
19:21 |
|
Quest |
cant load every role/permission at start/userlogin |
19:21 |
|
Naros |
right, but its no different than can a user create a new item in inventory, can they create a repair document, can they replan the material, can they createa a warranty for it. |
19:22 |
|
Quest |
ya. kind of. but the acts are so many. |
19:22 |
|
Naros |
all those evaluations are at runtime, but what a user can do is loaded only once at login. During the evaluation, we compare attributes of the item against what the user's authorizations are. |
19:22 |
|
Quest |
Naros, do you happen to have seen a working example for such kind or any point that would be relevent for me to look |
19:22 |
|
Quest |
on internet i mean |
19:22 |
|
Quest |
hm |
19:23 |
|
Naros |
Nope, security is very different based on app |
19:23 |
|
Quest |
Naros, so all the permissions are loaded when the user logs in? |
19:23 |
|
Naros |
In our case, yes. |
19:23 |
|
Quest |
wo wo ... let me show you something first then. |
19:23 |
|
Naros |
we load something like the following (pseudo) |
19:24 |
|
Naros |
AuthorizationObject('Inventory',{Facilities: 1,2,5,9,15}) |
19:24 |
|
Naros |
we load a series of authorization objects into the user session principal |
19:24 |
|
Naros |
then when we need to verify inventory access, we just find the inventory authorization object and compare whether taht facility is permissible |
19:25 |
|
Quest |
Naros, http://i42.tinypic.com/2912d8n.png there would be millions of tasks, and hundres of boxes, dozens of boards that a user may have acces to. now geting and saving privileges of each user for each task/board/box that is readable/writable/editable/ would be sane? |
19:25 |
|
Naros |
in your case, it could just be things like moderator, create, edit, or w/e |
19:25 |
|
Quest |
. |
19:25 |
|
Naros |
You could apply some filter on your queries |
19:26 |
|
Quest |
what kind of? thats what i was thinking. |
19:26 |
|
Quest |
"do this if user is logged in" |
19:26 |
|
Quest |
"do this if user xx permissions is true" |
19:26 |
|
Quest |
thats a seperate query though ^ |
19:27 |
|
sfisque |
blunted as in, only accessible from "inside". as for "static security" , how would you solve the issue of :: user A is logged in, Admin X removes authorities, user A continues to use the system with "old authorities" |
19:27 |
|
Quest |
sfisque, good point |
19:27 |
|
sfisque |
you HAVE to enforce AA live |
19:27 |
|
Quest |
very good point |
19:28 |
|
Quest |
I hope you read last 5- 7 lines of mine |
19:28 |
|
Naros |
sfisque: true, but that doesn't imply needing to requery teh DB for each request |
19:28 |
|
Quest |
Naros, true |
19:28 |
|
Naros |
there are other methods to accomplish that |
19:28 |
|
Quest |
Naros, but the user login. and sessions. yes it does. doesnt it? |
19:29 |
|
sfisque |
aye, but you're only other alternative is a call back system or a triggering system via JMX |
19:29 |
|
Quest |
if user logs in and session is created. but the user is welcomed by admin there after |
19:29 |
|
sfisque |
which means you're over designing for a small case |
19:29 |
|
Quest |
hm. nevermind. but what about my scenario |
19:29 |
|
Naros |
if you just shove the data into the session and verify from the session, you do get the issue sfisque mentions. You have to have a way that when permissions are modified and if the user is authenticated, the permissions table gets refreshed. |
19:30 |
|
Quest |
Naros, sfisque do you think i need spring aop to trigger / filter authentications before each access? |
19:30 |
|
Naros |
For us, the business process is that the user's session gets invalidated, forcing a relogin. |
19:30 |
|
Quest |
hm. |
19:30 |
|
sfisque |
aye but that could be undesirable ux, if you're elevating them, OR only removing a small portion of authority |
19:31 |
|
Naros |
sfisque: true. depends on the business cases imo |
19:31 |
|
Quest |
Naros, sfisque so after looking at http://i42.tinypic.com/2912d8n.png there would be millions of tasks, and hundres of boxes, dozens of boards that a user may have acces to. now geting and saving privileges of each user for each task/board/box that is readable/writable/editable/ would be sane? what do you suggest as a strategy where I cant load each permission / role at user login |
19:31 |
|
sfisque |
aye |
19:31 |
|
sfisque |
don't load them. use them via "joins" at the db level |
19:31 |
|
Naros |
joining them is a viable approach |
19:32 |
|
Quest |
sfisque, so the db query on actions , live? |
19:32 |
|
Quest |
what do you mean by join here? |
19:32 |
|
sfisque |
i need a list of widgets, so Select W where W.x = m AND (some set of joins that indicate if i have permission to load that object or object type) |
19:33 |
|
Quest |
hm |
19:33 |
|
Naros |
The unfortunate part is depending on the security model, applying this like the above can come with a certain performance hit. |
19:33 |
|
sfisque |
of course. you have to tune the queries appropriately |
19:33 |
|
sfisque |
using "exist" rather than direct joins, coalesce versus OR, etc. |
19:33 |
|
Quest |
ok. but what strategy / arhitecture for http://stackoverflow.com/questions/17793414/spring-3-hibernate-4-user-authentication-and-privileges how to do it |
19:34 |
|
Quest |
I mean at what level. |
19:34 |
|
Naros |
if you can determine the security values in a static fashion, you can improve performance greatly. |
19:34 |
|
Quest |
in reference to dao/ server/ controller |
19:34 |
|
sfisque |
i'll chime back in later. gotta bounce for commute. code strong! |
19:34 |
|
Quest |
ok |
19:34 |
|
Naros |
If you're going to join them in your queries, you're imposing some of that in the DAO itself |
19:35 |
|
Quest |
hm |
19:35 |
|
Naros |
But what you "show" is a different question than what you can do. |
19:36 |
|
Quest |
Naros, so before every saveOrUpdate(user); someAuthMehtod() is called to check whether the requester of this method have privilage to saveOrUpdate an other user? |
19:36 |
|
sfisque |
depends how you look at it. ultimately every authority is just "do i have token X in my perm pool" |
19:37 |
|
Naros |
Yes, generally that would be done as a check inside the service method. |
19:37 |
|
Quest |
2. Naros side question. why in dao , the saveOrUpdate(user) method also returns a user object to the service and ther service returns the user object to controller? I mean what is the need ? (else than when a user IS REQUIRED like in getUser(id)) ? |
19:38 |
|
Quest |
Naros, the problem is that the perm pool would go very very high. and we dont know which perm the user makes access to? e.g tries to get the 7th billionth task . |
19:38 |
|
Naros |
Because saving a new User entity assigns it an id. You might in turn need that User managed entity that is attached to the Hibernate session for another DAO call to something else. If that entity hasn't been persisted and an ID assigned and you pass in an unmanaged entity, Hibernate will complain. |
19:39 |
|
Naros |
It might be useful for saving a new user to redraw the UI and show the user id for the new record too. |
19:40 |
|
Quest |
Naros, oh. so the user is return because we may want to reuse that user else where too? (again in that controller/ service) ? |
19:40 |
|
Quest |
nice logic. |
19:40 |
|
Quest |
understandable. but i hope its not mandatory? |
19:41 |
|
Naros |
Security checks are highly application dependent quest. We designed ours to be high level enough so that we didn't have a bazillion authorizations but only a core set of a few hundred with some business logic wrapped around them so that an evaluator can inspect entity, and based on an authorization request determine whether it can proceed or fail. |
19:41 |
|
Quest |
hm |
19:41 |
|
Naros |
Quest: That's correct. The DAO is about datastore interactions only. But the API should be fluid enough that it can lend itself to a varying of actions that you might need in the service without you having to do something like INSERT followed by a SELECT. |
19:42 |
|
Naros |
Hibernate can quickly get the assigned ID and populate the entity with it without having to requery the full record. |
19:43 |
|
Naros |
Sorry, but I need to go afk for a few minutes. |
19:43 |
|
Quest |
Naros, my scenarios is like this. a user comes and a db query tels/lists the borads he has access to. when he enters a board. the boxes privileges are lists and only readable boxes are shown to him. then same with tasks. each of them has create/read/update/delete permision and that is known/fetched at the time when the user acts for one. e.g tries to create/read/update/delete a board/box/task. |
19:44 |
|
Quest |
now there are millions of boxes / tasks. loading permissions for each might be insane? |
19:44 |
|
Quest |
Naros, sure |
19:54 |
|
|
oO0Oo joined ##javaee |
19:55 |
|
|
joshua_jandyco joined ##javaee |
19:58 |
|
Naros |
back |
19:59 |
|
Naros |
you wouldn't load permissions for each task, yes that would be crazy. |
20:00 |
|
Naros |
but whether a user view tasks or create tasks might be something you can determine based on a broader security model. |
20:00 |
|
Naros |
but that depends solely on your application |
20:00 |
|
Quest |
welcome |
20:00 |
|
Naros |
for example, within board A, the user can view tasks only. they can't create/edit/delete tasks. |
20:01 |
|
Naros |
but within board B, the user has full permissions for tasks |
20:01 |
|
Naros |
such a case could be designed where CREATE_TASK permission is defined by a list of boards. |
20:01 |
|
Naros |
and that list is specific to the user who is logged into the application. |
20:02 |
|
Naros |
does that make any sense? |
20:02 |
|
Quest |
Naros, the level is not broad. the priviliege is based on each box/board/ for it and its children to be made/edited |
20:03 |
|
Quest |
or I think ... that : |
20:04 |
|
Quest |
we should first get all the privilieges of the user for the boards/ tasks it has any level of access.? |
20:04 |
|
Quest |
well that list can go huge. specially for admins |
20:04 |
|
Quest |
each login will be very slow.. |
20:04 |
|
Quest |
Naros, isnt the runtime way more appropriate? |
20:04 |
|
Naros |
This is an architecture question mainly, one which is going to be specific to your application. |
20:05 |
|
Quest |
user logs in > all the boards listed. user gets in one board. children of that board and privilieges get listed. so on.. |
20:05 |
|
Quest |
hm. |
20:05 |
|
Naros |
so you have a method called getUserBoards() |
20:05 |
|
Quest |
Naros, can you just point out the options I have? |
20:06 |
|
Quest |
Naros, yes. |
20:06 |
|
Naros |
it gets all the boards that the current user can click into |
20:06 |
|
Quest |
yes. |
20:06 |
|
Naros |
once they get to the point where the tasks are shown, you have a method called getBoardTasks() |
20:06 |
|
Quest |
that is. the borads with read access for the user |
20:06 |
|
Naros |
it gets all tasks that the user can see within a given board. |
20:06 |
|
Quest |
boards > boxes > tasks |
20:06 |
|
Quest |
yes. |
20:06 |
|
Naros |
design the API around your use cases. |
20:06 |
|
Naros |
modify where appropriate. |
20:07 |
|
Quest |
but.... when the user tries to create a task in a box. the privilige of user for that box is checked on runtime. db query. if the user can create sub childres of that box. its done. else error |
20:07 |
|
Naros |
build into your SQL queries where it makes sense filters on the data bsaed on the user. where it doesn't make sense, wrap the query around some java-code filtering or acecss checks where necessary. |
20:07 |
|
Quest |
the choice here is either do db check for each action or do a full fledge fetch all list. |
20:08 |
|
Naros |
Right, build it straight forward and then refactor where needed. |
20:08 |
|
Quest |
hm. |
20:08 |
|
Naros |
do it per action with a db check |
20:08 |
|
Naros |
once it works, find ways to tune |
20:08 |
|
Quest |
ok. let me send you my example clas of dao then. a minute |
20:09 |
|
Quest |
meanwhile, this ^ do not need spring security ? or is easiliy done with spring security? or do I need anything else? |
20:09 |
|
Naros |
people often get caught up in trying to design some elaborate way to do something when a simple way gets the ball going and you quickly see where you can refactor and make things more logical and structured. |
20:09 |
|
Naros |
id recommend at least spring security for the authentication/remember-me functionality |
20:10 |
|
Naros |
you can then do the DB checks as you need and perhaps find a way to integrate that back into spring security in a secondary development phase. |
20:12 |
|
Quest |
Naros, http://pastebin.com/A3xk322y |
20:13 |
|
Quest |
Naros, ok |
20:13 |
|
Naros |
There are a few ways to accomplish returning multiple values. |
20:13 |
|
Naros |
One way would be to return a tuple result |
20:13 |
|
Naros |
where the result is a combination of a User object and the boolean value. |
20:14 |
|
Naros |
We do this a lot in C++ to avoid having to return values in the parameter list . |
20:14 |
|
Naros |
Another way, which I dont necessarily advocate but works is to return the User object upon success, return null upon failure. |
20:15 |
|
Naros |
and the caller verifies if the result is a non-null value rather than true/false. |
20:15 |
|
Naros |
Another java-like way is to return the User object but upon failure, you throw an exception and the caller is responsible for catching it and doing whatever logic |
20:15 |
|
Quest |
oh ok. why wont you advocate the last? |
20:15 |
|
Quest |
second last now |
20:16 |
|
Quest |
Naros, can you show up the first one? tuple one? |
20:16 |
|
Naros |
That typically isn't very java-like and typically I see exceptions being thrown for this case |
20:17 |
|
Quest |
this would work fine = to return the User object upon success, return null upon failure. |
20:17 |
|
Naros |
The tuple scenario would be something like you have a class called SaveResult that has two properies, User and boolean status; |
20:18 |
|
Naros |
you create a SaveResult, set the user/status value and return the SaveResult |
20:18 |
|
Naros |
do you follow? |
20:18 |
|
Quest |
hm. |
20:18 |
|
|
sfisque joined ##javaee |
20:18 |
|
Quest |
cant make so many classes then. |
20:18 |
|
Naros |
That's why I said the java way is you let the method stub be |
20:18 |
|
Quest |
cant make so many classes then. for each type of auth. am.. well I think only one class may be fine in my case |
20:18 |
|
Naros |
User saveOrUpdate(User user) throw UserSaveException; |
20:19 |
|
Quest |
saveResult {Object, boolean} this will work for all |
20:19 |
|
Naros |
Let me show you a better way |
20:19 |
|
Quest |
okie dokie |
20:21 |
|
Naros |
http://pastebin.com/hpPkSBpW |
20:21 |
|
Naros |
This is using generics |
20:21 |
|
Naros |
You have 1 class that supports any object type without casts |
20:21 |
|
Naros |
The stub would then be |
20:21 |
|
Naros |
SaveResult<User> saveOrUpdate(User user); |
20:22 |
|
Naros |
but again my preference is to use exceptions rather than this hackery. |
20:22 |
|
Quest |
why wont you recomend this or the return null thing? |
20:22 |
|
Naros |
sorry, typo in getStatus() should be return result |
20:22 |
|
sfisque |
be careful with using generics "that way". it can promote some anti-patterns. |
20:23 |
|
Naros |
sfisque: that too but just showing Quest the way you can return multiple values in java from a method call. |
20:23 |
|
sfisque |
right. just cautioning him |
20:23 |
|
Naros |
I believe most of us in the Java world prefer this |
20:23 |
|
Naros |
User saveOrUpdate(User user) throws UserException; |
20:24 |
|
Naros |
or |
20:24 |
|
Naros |
User saveOrUpdate(User user) throws DatabaseException |
20:24 |
|
Naros |
or w/e you want to call it |
20:24 |
|
sfisque |
aye. i find generics are very nice for things like vistor or strategy patterns. but if (ab)used, it can lead to base-bean and/or call super anti-patterns |
20:25 |
|
Naros |
Allow the service to catch those specific exceptions, wrap them in an application specific exception and rethrow or rather handle as needed. |
20:25 |
|
sfisque |
yup |
20:26 |
|
Naros |
You dont run into thrashing your process space under the java world of exceptions as you would under the C++ world. |
20:26 |
|
Naros |
exceptions are actually frowned upon in the C++ world :P |
20:26 |
|
Naros |
hence the return null, verify non-null pattern I mentioned |
20:26 |
|
sfisque |
aye, but using execption handling as a "flow control" is another anti pattern. |
20:27 |
|
sfisque |
depending on the granularity of that operation, might be better to wrap the result in some "status return" object that carries the updated VO in addition to any other "results" |
20:27 |
|
Quest |
Naros, http://pastebin.com/sxuftdft |
20:27 |
|
whartung |
yea, testing exception is no bueno |
20:27 |
|
sfisque |
for these simple cases, throwing the exception works well. |
20:27 |
|
whartung |
they're supposed to be exceptions, not part of common processing |
20:28 |
|
Naros |
I just think using this SaveResult<T> concept for this type of case isn't ideal but maybe its just my preference. |
20:28 |
|
sfisque |
aye, but you'd be surprised how "common" it is to have things like "PasswordTooLongExceptioin", "PasswordNotCompliantException", etc. where these are actual workflow outcomes and not true "failures" |
20:29 |
|
Quest |
Naros, sfisque why not just return null on failure and the user object on succes. the call object will examine if it gets null or an object. and act accordingly? |
20:29 |
|
sfisque |
oh, don't get me wrong naros, it's a very useful paradigm. i was just noting for Q's welfare, that it can be a dangerous path if not treaded knowledgibly |
20:29 |
|
Quest |
Naros, is the paste i gave ok? |
20:29 |
|
Naros |
but dont forget that your checkifUseCanSaveOrUpdate() method may need information from the user or other contextual data besides just the actor. |
20:30 |
|
sfisque |
null is a sane value and does not necessarily indicate failure |
20:30 |
|
|
buharin joined ##javaee |
20:30 |
|
Naros |
Agreed, it's contextual based. |
20:30 |
|
sfisque |
that's the difference between a mathematician and a computer programmer |
20:30 |
|
sfisque |
null == very real and tangible value |
20:30 |
|
buharin |
hey, I need some help with eclipse and adding simple ejb to my webproject |
20:30 |
|
Quest |
sfisque, but the caller guy would evaluate it like if (call == null) {it means failure else do operation} |
20:31 |
|
buharin |
I create two of them and mavenize them and now idk how to add ejb to web |
20:31 |
|
sfisque |
i woudl argue it is a polluted or muddy api |
20:31 |
|
Naros |
but what happens if the API later needs to return null as a valid value? |
20:31 |
|
sfisque |
agree naros |
20:31 |
|
Naros |
it would just be easier to throw exceptions, catch & handle as appropriate. |
20:31 |
|
Quest |
sfisque, you mean the null thing? |
20:31 |
|
sfisque |
yes Q |
20:31 |
|
sfisque |
null should never be considered "an error case". |
20:31 |
|
Quest |
sfisque, what do you think of this http://pastebin.com/sxuftdft ? |
20:32 |
|
sfisque |
null can be the "result" or an "artifact" of an exception state, but itself should not communicate an error case |
20:32 |
|
Quest |
sfisque, Naros hm. null seemed easy as i am not expert with exceptions handling |
20:32 |
|
Naros |
let me show you Q |
20:32 |
|
Quest |
sfisque, ya. its technically not an error. its just null value. but but the caller guy would evaluate it like if (call == null) {it means failure else do operation} ? |
20:32 |
|
sfisque |
using null to indicate error is no better than using a value of "23" |
20:33 |
|
sfisque |
you're still using a "magic number" |
20:34 |
|
Quest |
hm |
20:35 |
|
Naros |
http://pastebin.com/CxgiZce3 |
20:35 |
|
Naros |
If the security check fails, you throw an exception |
20:35 |
|
Naros |
if the DAO fails, you catch it, throw a service specific exception |
20:35 |
|
Naros |
er like 13 shoul dbe |
20:36 |
|
Naros |
throw new UserException(e); |
20:36 |
|
Naros |
*line 13 |
20:36 |
|
Quest |
what would be done with new UserException(e); |
20:36 |
|
Quest |
I am weak with exceptions. |
20:36 |
|
Naros |
Quest: updated version here http://pastebin.com/sZrLPTA8 |
20:37 |
|
sfisque |
be careful though, because you're potentially obfuscating the original exception. if later code is looking for a SQLException or PersistenceException, the check will fail to discover it |
20:37 |
|
Quest |
I never intended you tutoring me thought :) |
20:37 |
|
Naros |
Your controller would catch UserException and handle it based on whatever UI logic is needed. |
20:37 |
|
Quest |
but its silly of me to not to have grasped exceptions |
20:37 |
|
Naros |
sfisque: very true |
20:37 |
|
sfisque |
exception handling is a subtle art |
20:37 |
|
sfisque |
:-P |
20:37 |
|
Naros |
that it is |
20:37 |
|
sfisque |
you will "get it" over time Q |
20:37 |
|
Quest |
can we go without exception handling? |
20:38 |
|
Naros |
i wouldn't recommend it |
20:38 |
|
Quest |
sfisque, ofcourse. i got what i have in the similar way |
20:38 |
|
Quest |
:) |
20:38 |
|
sfisque |
better to try and learn from mistakes, then to over simplify and learn nothing |
20:38 |
|
Naros |
It is something I strongly suggest you try to learn the basics for. |
20:38 |
|
sfisque |
anyone can write "hello world". |
20:39 |
|
Naros |
An exception is a way to inform the caller that something happened and leave it up to the caller on how it wants to handle it. Handling it may mean letting it bubble up to the caller's caller which could be your web framework |
20:39 |
|
Quest |
@PreAuthorize("#contact.name == authentication.name") ? |
20:39 |
|
Quest |
sfisque, hm |
20:39 |
|
Naros |
hehe spring security :P |
20:39 |
|
Quest |
hm: ) |
20:39 |
|
Naros |
that statement matches some method call with this |
20:40 |
|
Naros |
someMethod(Contact contact) |
20:40 |
|
Naros |
#contact refers to the parameter to the method "contact" |
20:40 |
|
sfisque |
well, i have to actually get work done today, so i'll be lurking but mostly "mentally away" :P |
20:40 |
|
sfisque |
code strong! |
20:40 |
|
Naros |
it says that the principal's name on the authentication object should be equal to the name property value of the contact parameter or else it throws AccessDeniedException |
20:41 |
|
Quest |
hm |
20:42 |
|
Quest |
Naros, how the caller acts to the exception accordingly? |
20:42 |
|
Naros |
try { service.callSomeMethod(contact); } catch(AccessDeniedException ex) { /* return the user to some exception page and tell them why */ } |
20:43 |
|
Naros |
that might be what your controller's run/execute method contains |
20:43 |
|
Naros |
basically allows you to do something different upon an exception |
20:43 |
|
Naros |
it doesn't necessarily have to dictate flow but in many cases of a web application it generally does. |
20:44 |
|
Quest |
oh. so the service method callsed the dao. and before that, the auth method in that dao, if exceptions occurs, the service method gets the exception and returns to controller. the controller then acts on the exception string and redirects etc? |
20:45 |
|
Naros |
Quest: http://docs.oracle.com/javase/tutorial/essential/exceptions/ |
20:45 |
|
Naros |
Quest: you got it! |
20:46 |
|
Naros |
Exceptions can mean anything -- they're entirely contextual |
20:46 |
|
Quest |
hm |
20:47 |
|
Naros |
Scratch that last statement, not sure what I meant by that in hindsight. |
20:47 |
|
Quest |
so returning null is not good at all? using the generic class is not perfect? using exceptions is the right way to go? |
20:48 |
|
Naros |
Null is definitely not the ideal approach in Java since null can mean various things. |
20:48 |
|
Naros |
it is a tangible thing |
20:48 |
|
Naros |
Exceptions and Tuples are the right tool where applicable. |
20:48 |
|
Naros |
But this particular use case, I'd prefer exceptions |
20:49 |
|
Naros |
If you have a scenario where under success you need to return 2+ values ... then tuple makes sense. |
20:49 |
|
Quest |
Naros, but if the caller checks for null? what is the problem? just asking for understanding |
20:50 |
|
Quest |
Naros, tuple was the generic class ? right? |
20:50 |
|
Naros |
The biggest issue is once you're at version 2, null may become a legit return value for a method call. Maybe not this method but some other method in your API. If you've been testing for != null, now you've got to change code in several places. |
20:50 |
|
Naros |
If you had used exceptions, changing things in the internal api code wouldn't have any impact because you aren't checking for != null |
20:50 |
|
Quest |
hm. |
20:51 |
|
Naros |
other than maybe needing to capture a new exception or two if applicable. |
20:51 |
|
Naros |
generally, it's cleaner and more acceptable code |
20:51 |
|
Naros |
and yes Tuple was the generic class but such a Tuple doesn't have to be a generic class. |
20:51 |
|
Quest |
and if i use the generic (tuple you say?) , that would also be same as you said changing things in the internal api code wouldn't have any impact because you aren't checking for != null ? |
20:51 |
|
Naros |
it could be a concrete class without generics |
20:52 |
|
Quest |
myclass havein and object and a boolean? |
20:52 |
|
Quest |
ok |
20:52 |
|
Quest |
so i have both options? |
20:52 |
|
Naros |
Perhaps not for this particular case, but i want to make sure you aren't using a nail gun when one should just be using a soft mallet |
20:52 |
|
Quest |
for me to work on. research |
20:52 |
|
Quest |
hm |
20:53 |
|
Naros |
In programming, there are often many tools that accomplish the same thing but have subtle differences and are just better options than others regardless if the outcome is the same. |
20:53 |
|
Quest |
buharin, whats your question |
20:54 |
|
Naros |
take my advice and use exceptions Quest. |
20:55 |
|
Naros |
at least for this. there are cases where a tuple or concrete return class is appropriate but those are generally not the case. |
20:55 |
|
Naros |
*but this isn't the case |
20:55 |
|
buharin |
fuck |
20:55 |
|
Naros |
buharin: ? |
20:55 |
|
buharin |
some niggas spam here and noone saw my question : / |
20:56 |
|
Quest |
Naros, the thing to get an object and two string ("success" or "failure", "message") by a generic/ nongenric class is looking more attractive to me. I hope iam technically sound at this? by this (rather than exception or boolean) I can change designe later, send any string, or even messages. |
20:56 |
|
Naros |
excuse me? No one was spamming but having a conversation which your question was made concurrenctly. You want to dd ejb support to a web eclipse project. |
20:56 |
|
Quest |
buharin, you can ask again |
20:57 |
|
javanewb |
without the racially charged slurs |
20:57 |
|
buharin |
Quest, no cause I will resolve it by myself |
20:58 |
|
Quest |
hm ok. |
20:58 |
|
whartung |
wow |
20:58 |
|
Naros |
No offense, but that's choice. Enjoy. |
20:58 |
|
Naros |
*that's your choice. |
20:58 |
|
Quest |
Naros, by using exceptions, I would be limited to return only a string of exception? no i gues |
20:58 |
|
whartung |
An exception can be anything |
20:58 |
|
Quest |
right |
20:59 |
|
javanewb |
exceptions is the way to go |
20:59 |
|
Quest |
hm. |
20:59 |
|
Naros |
Ask yourself this Q. |
20:59 |
|
Naros |
If save user fails, what information is important that you need on the UI ? |
20:59 |
|
Quest |
Naros, hm.. a string i gues |
20:59 |
|
Naros |
Chances are slim that you need nothing but just a user friendly message in 95% of the caes. |
20:59 |
|
Quest |
from string.properties |
20:59 |
|
Naros |
Right. |
21:00 |
|
Naros |
So catch the exception, generate your pretty i18n message and return the user to the designated jsp |
21:00 |
|
Quest |
hm.. i forgot / cant scroll and find what sfisque was pointing the dangeour for exceptions though |
21:00 |
|
Quest |
do you rembmer |
21:01 |
|
Naros |
yes he pointed out my obfuscating of the exception stack |
21:01 |
|
Quest |
hm. Naros thanks again .. and again thanks is a small word. |
21:01 |
|
Naros |
where I caught the SomeDaoException and then threw a new UserException |
21:01 |
|
Quest |
hm. |
21:01 |
|
Naros |
in some cases, that isn't the way to go, you may want that SomeDaoException to bubble up a few levels. |
21:01 |
|
Quest |
i have to be care ful then |
21:01 |
|
Naros |
but that is case by case. |
21:02 |
|
Naros |
But in the webapp world, I haven't found many of those where it's critical. |
21:02 |
|
Quest |
hm. |
21:03 |
|
Quest |
Naros, so uptil now. you think i should go for a manul thing as discussed. spring security comes later at refactoring stage or spring secrity just does not do what I want to do (authentical at runtime ) |
21:03 |
|
Quest |
? |
21:03 |
|
* Quest |
finalizing discussion ^ |
21:03 |
|
|
Maziz joined ##javaee |
21:04 |
|
Naros |
I think Spring security is something you may want to consider at the start to handle the authentication and session management |
21:04 |
|
Quest |
agreed. |
21:04 |
|
Naros |
You can tie in your permissions checks with it in a second phase later on but for now do your own security checks |
21:04 |
|
Quest |
but what about authorization |
21:04 |
|
Quest |
authorization and not authentication |
21:04 |
|
Naros |
Right let it handle authentication. |
21:05 |
|
Quest |
so spring can tie those on runtime dao calls? |
21:05 |
|
Naros |
As for authorizations, do that manually as you proposed. |
21:05 |
|
Quest |
so. manually is what you suggest? or spring? or spring CANT do it on runtime as I proposed in manual way? |
21:05 |
|
Naros |
You can have spring security do some method permission evaluations at runtime but they aren't necessary. |
21:06 |
|
* Quest |
provides that spring roles is not what the case here is |
21:06 |
|
Quest |
hm. |
21:06 |
|
Naros |
Right don't worry about the role stuff that spring security talks about. |
21:06 |
|
Quest |
meaning? |
21:06 |
|
Naros |
Spring security basically would provide you a UserDetailsService where it looks up a user by name and returns an object (I think this is called SessionUser or something). |
21:07 |
|
Quest |
ok. |
21:07 |
|
Naros |
you have to code this service to wire it into your dao methods via the xml configs of course. |
21:07 |
|
Quest |
what about authorisation for each board/box/task |
21:07 |
|
Naros |
do that manually with database queries |
21:07 |
|
Quest |
xml is what i hate........ |
21:07 |
|
Quest |
@anotatons ? |
21:07 |
|
crimsonfubot |
Quest: Error: "anotatons" is not a valid command. |
21:07 |
|
Quest |
lol |
21:07 |
|
Quest |
@commands |
21:07 |
|
crimsonfubot |
Quest: Error: "commands" is not a valid command. |
21:07 |
|
Quest |
@help |
21:07 |
|
crimsonfubot |
Quest: (help [<plugin>] [<command>]) -- This command gives a useful description of what <command> does. <plugin> is only necessary if the command is in more than one plugin. |
21:08 |
|
Naros |
Don't bother with the @PreAuthorize/@PostAuthorize and Filter annotations until you get a better understanding of your security model. |
21:08 |
|
Quest |
@command |
21:08 |
|
crimsonfubot |
Quest: Error: "command" is not a valid command. |
21:08 |
|
whartung |
haha -- @help was not helpful |
21:08 |
|
Naros |
@help exception |
21:08 |
|
crimsonfubot |
Naros: Error: There is no command "exception". |
21:08 |
|
Quest |
Naros, ok. and finally..... what do you see the finall refactor would be? |
21:08 |
|
Naros |
hehe, no way I can answer that Quest. |
21:09 |
|
Naros |
You're the keeper of your code base :P |
21:09 |
|
Quest |
Naros, ok. :) what do you see a choice that would be your choice at the end? |
21:09 |
|
Naros |
But here is what I can tell you though. |
21:09 |
|
Naros |
At the end, map out all your permissions to actions |
21:09 |
|
Naros |
Try to find a way to define a finite combination of these |
21:10 |
|
Naros |
use that to drive your roles |
21:10 |
|
Naros |
then plug those roles into spring security |
21:10 |
|
Naros |
then using a permissions evaluator (interface which you implement and write your own checks), you can then plug into the preauthorize/postauthorize/filter annotations |
21:10 |
|
Quest |
hm. so ultimately, you see all to be done by spring security ? |
21:10 |
|
Naros |
I would suspect a lot of it could be |
21:11 |
|
Naros |
Not all, but a lot of it. |
21:11 |
|
Naros |
With anything, there are always things that won't fit a paradigm and those are just things we have to sometimes live with :P |
21:11 |
|
Naros |
just minimize the exposure to the trickery needed as best as one can |
21:11 |
|
Quest |
Naros, last question. the admin might be using hundres of boards, thousands of boxes and millions of tasks. it wont be wise to fetch privileges of alllll those at admin login. thats what spring does. |
21:12 |
|
Naros |
Right and nothing says those necessarily have to be loaded at login either. think about this for a minute. |
21:12 |
|
Naros |
lets say we show a maximum of 25 tasks on the screen at a time |
21:13 |
|
Quest |
no. |
21:13 |
|
Naros |
? |
21:13 |
|
Quest |
all tasks would be shown |
21:13 |
|
Quest |
as much as exist |
21:13 |
|
Quest |
oh wait |
21:13 |
|
Naros |
You aren't going to draw a million tasks on the screen at once |
21:13 |
|
Naros |
and i hope you aren't planning to draw 1000s either |
21:13 |
|
Quest |
but even the admin views them or not. spring wil get all his boards and sub childs |
21:13 |
|
Quest |
and privs of all |
21:14 |
|
Naros |
It doesn't necessarily have to is my point. |
21:14 |
|
Quest |
oh |
21:14 |
|
Quest |
so in short. |
21:14 |
|
Naros |
Here's a real world example. |
21:14 |
|
Quest |
spring can be configured to do exactly what we just discussed manually |
21:14 |
|
Quest |
ok |
21:14 |
|
Quest |
or just for the board he is viewing |
21:14 |
|
Naros |
A user decides they want to view an order in the system. An order has potentially 1000s of lines but maybe some of those lines can't be visible to the user because of some pricing contracts. |
21:15 |
|
Quest |
hm |
21:15 |
|
Naros |
We can either 1) fetch the order with only the visible lines by pushing the security constraints to the DB query |
21:15 |
|
Naros |
or 2) fetch the order and all lines, iterate the lines and wed out which aren't to be visible through a permissions evaluator. |
21:16 |
|
Naros |
Depending on the test case, 1 might be faster than 2 |
21:16 |
|
Quest |
hm |
21:16 |
|
Quest |
ok |
21:16 |
|
Naros |
But if you're OK with having your security model dip into the DAO level, then fine. |
21:17 |
|
Quest |
I just get afraid of huge refactoring when converting to spring security (which ultimately i would learn) |
21:17 |
|
Naros |
Spring Security can be configured to do whatever you want it to do and you get to pick how you implement the fine security details, whether u do it through their annotations & permission evaluator framework or you just do the checks yourself without worrying about spring and just let it handle the authentication part only. |
21:17 |
|
Quest |
or the same daos will be used? |
21:18 |
|
Quest |
hm |
21:18 |
|
Quest |
ok |
21:18 |
|
Quest |
Thanks! |
21:18 |
|
Naros |
trying to handle authentication can be tricky depending on your needs is the bottom line and if you can use an existing tried framework, its best to do that |
21:19 |
|
Naros |
authorization management can be a custom solution you design yourself outside spring |
21:20 |
|
Quest |
iam admin, you are user. you loged in and i deleted your account. now you session still exists, how to stop you (manual way) ? how to invalidate your session |
21:21 |
|
Naros |
we have a way in our app that specific admin screens can iterate all sessions and invalidate a specific one by session id. |
21:21 |
|
Quest |
so the admin first have to see all the sessions and find out the user first |
21:21 |
|
Naros |
not necessarily. |
21:22 |
|
Quest |
well the software would return the user session id by its login cred |
21:22 |
|
Quest |
understandable. |
21:22 |
|
Quest |
but this feature would have to be built up |
21:22 |
|
Quest |
thanks again |
21:22 |
|
Naros |
your code could take the user account's id or user name, iterate the session registry for spring security to find where the user is logged in under that name and then invalidate it. |
21:22 |
|
Quest |
time to close.... |
21:22 |
|
Quest |
hm |
21:22 |
|
Quest |
right. |
21:22 |
|
Quest |
see you!.. thanks alot again ! |
21:23 |
|
Naros |
Np |
21:23 |
|
Quest |
:) |
21:23 |
|
javanewb |
close? |
21:23 |
|
Naros |
Safe coding! |
21:23 |
|
javanewb |
you work at mcdonalds? |
21:23 |
|
Quest |
office close |
21:23 |
|
Quest |
yup |
21:23 |
|
Naros |
It's only 425pm :o |
21:23 |
|
Naros |
I wanna work where u work |
21:24 |
|
sfisque |
14:25 here pacific time |
21:24 |
|
Naros |
:P |
21:26 |
|
javanewb |
EST is the only true time |
21:27 |
|
Naros |
I used to be EST before I moved from Charlotte |
21:31 |
|
sfisque |
the only true time is zero seconds after the big bang. after that, it's all relative :P |
21:35 |
|
Naros |
:) |
21:36 |
|
|
caverdude joined ##javaee |
21:36 |
|
caverdude |
hi |
21:36 |
|
* sfisque |
waves |
21:36 |
|
caverdude |
sfisque, are you snyncsys_ |
21:37 |
|
caverdude |
on dalnet |
21:37 |
|
sfisque |
negative |
21:37 |
|
caverdude |
ah |
21:37 |
|
sfisque |
i only go by sfisque |
21:37 |
|
caverdude |
ok |
21:37 |
|
Naros |
hello caverdude. |
21:37 |
|
sfisque |
... there can be... only ONE... |
21:37 |
|
caverdude |
hi Naros |
21:37 |
|
sfisque |
:P |
21:37 |
|
Naros |
more like we can only take just one :P |
21:38 |
|
Naros |
multiples would be >.< |
21:38 |
|
sfisque |
lolz |
21:42 |
|
Naros |
hm, I wonder how many lines of code are too much in a web app (excluding resources like .jsp/.js/.css/etc) |
21:45 |
|
caverdude |
too much? |
21:45 |
|
caverdude |
I've heard you want not much more than 20 lines per method in general |
21:46 |
|
caverdude |
but its about that way with anything.. if it begins to grow too much you have to split it up |
21:46 |
|
sfisque |
the only judge of "too much" i would put any stock in, would be "code coverage". if you have code that is not getting executed, you ahve "too much" |
21:46 |
|
caverdude |
to answer you question you shouldn't have more lines of code than your hard drive will hold lol |
21:47 |
|
caverdude |
well, yes and with any app development, if you are removing more lines of code than you are writing you are probably on the right track |
21:48 |
|
caverdude |
my latest coding work is http://www.sf.net/p/javaledger |
21:49 |
|
caverdude |
its a very basic acccounting engine more or less |
21:53 |
|
Naros |
We're approaching 1M LOC in our webapp is why i asked. |
21:53 |
|
sfisque |
LOC? logged on concurrently? |
21:53 |
|
Naros |
Lines of Code |
21:54 |
|
sfisque |
do you run any code hygiene tools on the project? (PMD, code coverage, etc.) |
21:54 |
|
Naros |
no |
21:55 |
|
sfisque |
that would be a good first start. you can wire up most hygiene tools into CI environments (jenkins has off the shelf plugins for it) |
21:55 |
|
sfisque |
isolate code that is "orphaned" or "needing refactory" |
21:56 |
|
Naros |
cool, will do |
21:56 |
|
|
Quest joined ##javaee |