March 2008 - jboss-dev-forums - Jboss List Archives

[TODO - DEVELOPMENT] - HttpOnly cookie flag

by jmanico

Hello. Are there any plans to support the HttpOnly cookie flag in the session cookie (JSESSIONID) of JBoss? Tomcat is on route to support this security flag. As a side note, the HttpOnly cookie flag blocks JavaScript from accessing cookie data. It is supported by IE6+ FireFox 2.0.0.5+ Opera 9.5+ and is still be developed on Safari. It's not a standard per-say but is very widely used in practice. The Java Server JSR is also considering this flag. The security benefits are very significant. There is never, ever a need to access the JSESSIONID cookie via JavaScript. But adding HttpOnly support to JBoss a large class of Cross Site Scripting and Session Hijacking attacked will be prevented. Thank you!! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138439#4138439 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4138439

18 years

1
0
0 / 0

[Design of JBoss jBPM] - Re: iCalendar wrapper

by kukeltje

anonymous wrote : | I wonder if we can separate the channel discussion from the mapping between iCalendar and jBPM Yes, good suggestion. Sorry for threadjacking ;-) Personally, I'd wonder if DTSTART, LOCATION, PERCENT and CLASS can be left out for now. The task variables should be as easily readable as possible, so I'd not go for X- properties. Putting them in the description would also not be my favourite, so that leaves the ATTACH option or leave them out completely (at first). Additionally, I'd include a link somewhere that directly opens the task form page. For me that would be a near-perfect first release. A XUL based ui could be nice, but why not just use the /a webbased page for updating? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138417#4138417 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4138417

18 years

1
0
0 / 0

[Design of JBoss jBPM] - Re: iCalendar wrapper

by aapthorp

I wonder if we can separate the channel discussion from the mapping between iCalendar and jBPM (inparticular TaskInstance). First for read and then for create / update...the semantics should be the same irrespective of channel (e-mail, HTTP, RSS, etc). First mapping iCalendar properties to jBPM. I chose to map to VTODO (tasklist). The mapping of many properties is fairly obvious. As noted in my orginal post a few properties don't have obvious mappings: DTSTART (scheduled start date) LOCATION / GEO (location of task) PERCENT (percent complete) CATEGORIES (could map to task name?) CLASS (privacy) RESOURCES (I mapped actors to attendees) STATUS (e.g. assigned, accepted, declined, etc) So one obvious question is whether any of the above have equivalents in jBPM or do they point to extensions for jBPM? From Tom's earlier response it sounds like assignment state will be supported in 4. As a matter of interest what have you intended for the task management module now shown in the jBPM 'architecture' graphic? In looking at it the other way round (i.e. what can't be mapped from jBPM) the obvious question is how to deal with task specific variables? Are there any others? I can see three possibilities for task specific variables, an ATTACH (atttachment), embed them in the DESCRIPTION (currently only plain text) or 'X-' properties. Of course the question is how would a calendar user agent handle these? DESCRIPTION is fine for read only, but if we want to update? I was wondering with a XUL based UI such as Lightning / Sunbird if one could create task specific UIs that extend the basic calendar agent functionality... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138406#4138406 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4138406

18 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: WARNING: Preparing release of MC betas

by jason.greene＠jboss.com

I am surprised you didnt devise a way to restrict access to the snapshot server to only you :) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138387#4138387 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4138387

18 years

1
0
0 / 0

[Design of EJB 3.0] - Re: EJB3Deployer and EJB3ClientDeployer order

by alex.loubyansky＠jboss.com

Yes, I see now, thanks. It does look into the JBoss5DeploymentScope which is empty at the moment but the whole point is not to find the deployment it depends on but to make sure it's not a dependency on self. So, that's fine. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138385#4138385 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4138385

18 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: WARNING: Preparing release of MC betas

by adrian＠jboss.org

I'm all done, if I don't see the word SNAPSHOT for the rest of my of life it will be too soon. ;-) Now on to CR1 !!!! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138384#4138384 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4138384

18 years

1
0
0 / 0

[Design of JBoss Build System] - Re: License linking in poms

by adrian＠jboss.org

"pgier" wrote : Is it ok to put this URL to the lgpl in our poms? | http://www.gnu.org/licenses/lgpl-2.1.txt | | Instead of the copy we currently use | http://repository.jboss.org/licenses/lgpl.txt | | The maven convention is to point to the site of the license organization. If it's not ok, should we rename the file in our repository lgpl-2.1.txt so that it's not confused with 3.0. | That's not a question for the forums, its a question for the lawyers. ;-) IANAL but, the relevant part is here: anonymous wrote : | You may copy and distribute verbatim copies of the Library's | complete source code as you receive it, in any medium, provided that | ... and distribute a copy of this License along with the | Library. | So we should have our own copy of the license in the same place as where the library is distributed. Maven conventions are just that (design by exception). The conventions don't work in all circumstances. :-) Just copy it to lgpl-2.1. Don't rename it, otherwise you'll invalidate all the previous links. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138379#4138379 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4138379

18 years

1
0
0 / 0

[Design of JBoss Build System] - License linking in poms

by pgier

Is it ok to put this URL to the lgpl in our poms? http://www.gnu.org/licenses/lgpl-2.1.txt Instead of the copy we currently use http://repository.jboss.org/licenses/lgpl.txt The maven convention is to point to the site of the license organization. If it's not ok, should we rename the file in our repository lgpl-2.1.txt so that it's not confused with 3.0. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138376#4138376 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4138376

18 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: WARNING: Preparing release of MC betas

by adrian＠jboss.org

18 years

1
0
0 / 0

[Design of EJB 3.0] - Re: @SecurityDomain changes from AS42 to AS5

by anil.saldhana＠jboss.com

This is a package correction done by the ejb3 team. For AS5, I can move the annotation to "org.jboss.security.annotation.SecurityDomain" as this is the right place for the annotation. For the code in Branch_4, I am not sure how much the ejb3 team wants to change things. Carlo/BillD, comments. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138366#4138366 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4138366

18 years

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums March 2008