[JBoss JIRA] (JBIDE-23174) Missing validation of @SecuredReturn
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23174?page=com.atlassian.jira.plugi... ]
Alexey Kazakov updated JBIDE-23174:
-----------------------------------
Issue Type: Feature Request (was: Bug)
> Missing validation of @SecuredReturn
> ------------------------------------
>
> Key: JBIDE-23174
> URL: https://issues.jboss.org/browse/JBIDE-23174
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: cdi-extensions
> Affects Versions: 4.4.1.Final
> Reporter: Lukáš Valach
> Fix For: 4.5.x
>
> Attachments: SecuredReturn-Log, securedReturn.zip
>
>
> CDI extension DeltaSpike allows to create custom autorizer which decides whether the secured method invocation should proceed. It is possible to base the authorization logic on the result of the secured method - using annotation @SecuredReturn. (See [documentation of Deltaspike/Security Module|https://deltaspike.apache.org/documentation/security.html#Simplein...])
> When the return type of the secured method doesn't match the type of authorizer method parameter annotated with @SecuredReturn then application fail with exception "SecurityDefinitionException: No matching authorizer found for security". Validator doesn't detect any problems.
> This issue can be reproduced on attached project [^securedReturn.zip]
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (JBIDE-23174) Missing validation of @SecuredReturn
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23174?page=com.atlassian.jira.plugi... ]
Alexey Kazakov updated JBIDE-23174:
-----------------------------------
Fix Version/s: 4.5.x
> Missing validation of @SecuredReturn
> ------------------------------------
>
> Key: JBIDE-23174
> URL: https://issues.jboss.org/browse/JBIDE-23174
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: cdi-extensions
> Affects Versions: 4.4.1.Final
> Reporter: Lukáš Valach
> Fix For: 4.5.x
>
> Attachments: SecuredReturn-Log, securedReturn.zip
>
>
> CDI extension DeltaSpike allows to create custom autorizer which decides whether the secured method invocation should proceed. It is possible to base the authorization logic on the result of the secured method - using annotation @SecuredReturn. (See [documentation of Deltaspike/Security Module|https://deltaspike.apache.org/documentation/security.html#Simplein...])
> When the return type of the secured method doesn't match the type of authorizer method parameter annotated with @SecuredReturn then application fail with exception "SecurityDefinitionException: No matching authorizer found for security". Validator doesn't detect any problems.
> This issue can be reproduced on attached project [^securedReturn.zip]
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (JBIDE-23174) Missing validation of @SecuredReturn
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23174?page=com.atlassian.jira.plugi... ]
Alexey Kazakov reassigned JBIDE-23174:
--------------------------------------
Assignee: Alexey Kazakov
> Missing validation of @SecuredReturn
> ------------------------------------
>
> Key: JBIDE-23174
> URL: https://issues.jboss.org/browse/JBIDE-23174
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: cdi-extensions
> Affects Versions: 4.4.1.Final
> Reporter: Lukáš Valach
> Assignee: Alexey Kazakov
> Fix For: 4.5.x
>
> Attachments: SecuredReturn-Log, securedReturn.zip
>
>
> CDI extension DeltaSpike allows to create custom autorizer which decides whether the secured method invocation should proceed. It is possible to base the authorization logic on the result of the secured method - using annotation @SecuredReturn. (See [documentation of Deltaspike/Security Module|https://deltaspike.apache.org/documentation/security.html#Simplein...])
> When the return type of the secured method doesn't match the type of authorizer method parameter annotated with @SecuredReturn then application fail with exception "SecurityDefinitionException: No matching authorizer found for security". Validator doesn't detect any problems.
> This issue can be reproduced on attached project [^securedReturn.zip]
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (JBIDE-23174) Missing validation of @SecuredReturn
by Lukáš Valach (JIRA)
Lukáš Valach created JBIDE-23174:
------------------------------------
Summary: Missing validation of @SecuredReturn
Key: JBIDE-23174
URL: https://issues.jboss.org/browse/JBIDE-23174
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: cdi-extensions
Affects Versions: 4.4.1.Final
Reporter: Lukáš Valach
Attachments: SecuredReturn-Log, securedReturn.zip
CDI extension DeltaSpike allows to create custom autorizer which decides whether the secured method invocation should proceed. It is possible to base the authorization logic on the result of the secured method - using annotation @SecuredReturn. (See [documentation of Deltaspike/Security Module|https://deltaspike.apache.org/documentation/security.html#Simplein...])
When the return type of the secured method doesn't match the type of authorizer method parameter annotated with @SecuredReturn then application fail with exception "SecurityDefinitionException: No matching authorizer found for security". Validator doesn't detect any problems.
This issue can be reproduced on attached project [^securedReturn.zip]
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (JBIDE-23039) Need an interactive terminal that fits specific requirements
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23039?page=com.atlassian.jira.plugi... ]
Martin Malina commented on JBIDE-23039:
---------------------------------------
{quote}
Have you tried to set the VAGRANT_DETECTED_OS environment variable for the process you create?
{quote}
AFAIK, [~rob.stryker] does set up this variable when launching cdk on Windows. But I can't check atm so I'll let Rob clarify that.
> Need an interactive terminal that fits specific requirements
> ------------------------------------------------------------
>
> Key: JBIDE-23039
> URL: https://issues.jboss.org/browse/JBIDE-23039
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: server
> Affects Versions: 4.4.1.AM2
> Reporter: Rob Stryker
> Assignee: Rob Stryker
> Fix For: 4.4.2.AM1
>
> Attachments: vagranttty.png
>
>
> CDK Tools requires a terminal that allows interactivity of i/o. The full set of requirements is a bit difficult to find a solution for.
> 1) I must be able to get a Process or IProcess object when a command is run
> 2) I must be able to get an event or know when the process terminates
> 3) The terminal or console must be interactive and allow user input when prompted.
> 4) It must behave as in 3) for 'vagrant' commands and any and all associated plugins.
> These three requirements thus far seem impossible to solve. Solutions that have been attempted are:
> 1) Creating a java Process by myself via Runtime.exec. The interactive prompts never arrive and there is no API for Process to know when it is waiting for input.
> 2) Using the external-tools launch configuration. When running a command like mvn, the console that pops up seems to allow input from the user, and functions as expected. However, when running a command such as vagrant, such prompts are not provided. In our usecase, the following behavior is observed:
> a) During vagrant-registration prompts, the console indicates it is not a TTY terminal and cannot allow input
> b) During a landrush prompt for superuser status, no prompt is made, no TTY message is listed, and the process appears to have frozen
> 3) Launching / Opening a tm.terminal view. This solution fails requirements 1 and 2. We are not able to get a Process or an IProcess when a command is launched in a proper interactive terminal. This means we can have no way to know when the process has completed.
> Other options have been explored but ended up at dead ends and not worth mentioning. The real question is why interactive behavior is visible when using external-tools launch config for maven, but is not visible when running vagrant.
> Is this a function of the way the vagrant commands display or prompt for input? Why does vagrant-registration require a TTY terminal, but maven does not? Is this something that can be fixed upstream?
> No other obvious solutions have presented themselves in the past year.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (JBIDE-23173) Missing validation of @SecurityParameterBinding
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23173?page=com.atlassian.jira.plugi... ]
Alexey Kazakov updated JBIDE-23173:
-----------------------------------
Fix Version/s: 4.4.x
> Missing validation of @SecurityParameterBinding
> -----------------------------------------------
>
> Key: JBIDE-23173
> URL: https://issues.jboss.org/browse/JBIDE-23173
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: cdi-extensions
> Affects Versions: 4.4.1.Final
> Reporter: Lukáš Valach
> Fix For: 4.4.x
>
> Attachments: SecurityBindingType-Log.txt, securityParameterBinding.zip
>
>
> CDI extension DeltaSpike allows to create custom @SecurityParameterBinding types.
> These types allows to inject parameters values from the method invocation to authorizer bean. (See [documentation of Deltaspike/Security Module|https://deltaspike.apache.org/documentation/security.html#Simplein...]).
> When I create my own security parameter
> {code:java}
> @SecurityParameterBinding
> public @interface MySecurityParameter {
> }
> {code}
> ...and authorizer
> {code:java}
> public class CustomAuthorizer {
>
> @Secures
> @CustomSecurityBinding()
> public boolean check(@MySecurityParameter String parameter) {
> return true;
> }
> }
> {code}
> ...then I can secure some methods, but these methods must have appropriate input parameter with correct type and with the annotation
> {code:java}
> public class SecuredBean {
> //OK
> @CustomSecurityBinding()
> public SecuredBean doSomething(@MySecurityParameter String parameter) {
> return null;
> }
>
> //Not-OK (Missing @MySecurityParameter annotation)
> @CustomSecurityBinding()
> public SecuredBean doSomething2(String parameter) {
> return null;
> }
>
> //Not-OK (Bad type - Integer)
> @CustomSecurityBinding()
> public SecuredBean doSomething3(@MySecurityParameter Integer parameter) {
> return null;
> }
> }
> {code}
> Methods doSomething 2 and 3 cause an exception "SecurityDefinitionException: No matching authorizer found for security". Validator doesn't detect any problems.
> The attached project can be use to reproduce this issue [^securityParameterBinding.zip].
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (JBIDE-23039) Need an interactive terminal that fits specific requirements
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23039?page=com.atlassian.jira.plugi... ]
Martin Malina edited comment on JBIDE-23039 at 9/15/16 9:22 AM:
----------------------------------------------------------------
[~rob.stryker], I tried the PR on Mac. I started CDK 2.2 rc3. I disabled the SUB_ variables, so it asked me for credentials during startup. This worked as expected, I was able to enter them in the Terminal view. Everything seemed just fine:
{code}
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Importing base box 'cdkv2'...
==> default: Matching MAC address for NAT networking...
==> default: Setting the name of the VM: rhel-ose_default_1473941651986_62531
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
default: Adapter 1: nat
default: Adapter 2: hostonly
==> default: Forwarding ports...
default: 22 (guest) => 2222 (host) (adapter 1)
==> default: Running 'pre-boot' VM customizations...
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
default: SSH address: 127.0.0.1:2222
default: SSH username: vagrant
default: SSH auth method: private key
default: Warning: Remote connection disconnect. Retrying...
default:
default: Vagrant insecure key detected. Vagrant will automatically replace
default: this with a newly generated keypair for better security.
default:
default: Inserting generated public key within guest...
default: Removing insecure key from the guest if it's present...
default: Key inserted! Disconnecting and reconnecting using new SSH key...
==> default: Machine booted and ready!
==> default: Registering box with vagrant-registration...
default: Would you like to register the system now (default: yes)? [y|n]y
default: username: mmalina1(a)redhat.com
default: password:
==> default: Registration successful.
==> default: Checking for guest additions in VM...
default: No guest additions were detected on the base box for this VM! Guest
default: additions are required for forwarded ports, shared folders, host only
default: networking, and more. If SSH fails on this machine, please install
default: the guest additions and repackage the box to continue.
default:
default: This is not an error message; everything may continue to work properly,
default: in which case you may ignore this message.
==> default: Configuring and enabling network interfaces...
==> default: Copying TLS certificates to /Users/rasp/jbossqa/cdk2.2.rc3/cdk/components/rhel/rhel-ose/.vagrant/machines/default/virtualbox/docker
==> default: Mounting SSHFS shared folder...
==> default: Mounting folder via SSHFS: /Users/rasp => /Users/rasp
==> default: Checking Mount..
==> default: Checking Mount..
==> default: Folder Successfully Mounted!
==> default: Docker service configured successfully...
==> default: Running provisioner: shell...
default: Running: inline script
==> default: Running provisioner: shell...
default: Running: inline script
==> default: Running provisioner: shell...
default: Running: inline script
==> default:
==> default: Successfully started and provisioned VM with 2 cores and 3072 MB of memory.
==> default: To modify the number of cores and/or available memory set the environment variables
==> default: VM_CPU respectively VM_MEMORY.
==> default: You can now access the OpenShift console on: https://10.1.2.2:8443/console
==> default: To use OpenShift CLI, run:
==> default: $ vagrant ssh
==> default: $ oc login
==> default:
==> default: Configured users are (<username>/<password>):
==> default: openshift-dev/devel
==> default: admin/admin
==> default:
==> default: If you have the oc client library on your host, you can also login from your host.
{code}
But after it finished, I got an error pop up:
Starting Container Development Environment has encountered a problem.
Server Container Development Environment failed to start.
An exception stack trace is not available.
The same is in the error log.
The result is that CDK is actually up an running (vagrant status says "running", service manager returns the correct values), but in Servers view it is shown as stopped.
Then I tried again with a new workspace, this time I used brand new CDK 2.2 rc5 (which I just confirmed works fine with devstudio 10.1) and didn't even change the SUB_ vars setup. But it failed exactly the same way.
was (Author: mmalina):
[~rob.stryker], I tried the PR on Mac. I started CDK 2.2 rc3. I disabled the SUB_ variables, so it asked me for credentials during startup. This worked as expected, I was able to enter them in the Terminal view. Everything seemed just fine:
{code}
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Importing base box 'cdkv2'...
==> default: Matching MAC address for NAT networking...
==> default: Setting the name of the VM: rhel-ose_default_1473941651986_62531
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
default: Adapter 1: nat
default: Adapter 2: hostonly
==> default: Forwarding ports...
default: 22 (guest) => 2222 (host) (adapter 1)
==> default: Running 'pre-boot' VM customizations...
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
default: SSH address: 127.0.0.1:2222
default: SSH username: vagrant
default: SSH auth method: private key
default: Warning: Remote connection disconnect. Retrying...
default:
default: Vagrant insecure key detected. Vagrant will automatically replace
default: this with a newly generated keypair for better security.
default:
default: Inserting generated public key within guest...
default: Removing insecure key from the guest if it's present...
default: Key inserted! Disconnecting and reconnecting using new SSH key...
==> default: Machine booted and ready!
==> default: Registering box with vagrant-registration...
default: Would you like to register the system now (default: yes)? [y|n]y
default: username: mmalina1(a)redhat.com
default: password:
==> default: Registration successful.
==> default: Checking for guest additions in VM...
default: No guest additions were detected on the base box for this VM! Guest
default: additions are required for forwarded ports, shared folders, host only
default: networking, and more. If SSH fails on this machine, please install
default: the guest additions and repackage the box to continue.
default:
default: This is not an error message; everything may continue to work properly,
default: in which case you may ignore this message.
==> default: Configuring and enabling network interfaces...
==> default: Copying TLS certificates to /Users/rasp/jbossqa/cdk2.2.rc3/cdk/components/rhel/rhel-ose/.vagrant/machines/default/virtualbox/docker
==> default: Mounting SSHFS shared folder...
==> default: Mounting folder via SSHFS: /Users/rasp => /Users/rasp
==> default: Checking Mount..
==> default: Checking Mount..
==> default: Folder Successfully Mounted!
==> default: Docker service configured successfully...
==> default: Running provisioner: shell...
default: Running: inline script
==> default: Running provisioner: shell...
default: Running: inline script
==> default: Running provisioner: shell...
default: Running: inline script
==> default:
==> default: Successfully started and provisioned VM with 2 cores and 3072 MB of memory.
==> default: To modify the number of cores and/or available memory set the environment variables
==> default: VM_CPU respectively VM_MEMORY.
==> default: You can now access the OpenShift console on: https://10.1.2.2:8443/console
==> default: To use OpenShift CLI, run:
==> default: $ vagrant ssh
==> default: $ oc login
==> default:
==> default: Configured users are (<username>/<password>):
==> default: openshift-dev/devel
==> default: admin/admin
==> default:
==> default: If you have the oc client library on your host, you can also login from your host.
{code}
But after it finished, I got an error pop up:
Server Container Development Environment failed to start.
An exception stack trace is not available.
And then the tooling stopped the box.
> Need an interactive terminal that fits specific requirements
> ------------------------------------------------------------
>
> Key: JBIDE-23039
> URL: https://issues.jboss.org/browse/JBIDE-23039
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: server
> Affects Versions: 4.4.1.AM2
> Reporter: Rob Stryker
> Assignee: Rob Stryker
> Fix For: 4.4.2.AM1
>
> Attachments: vagranttty.png
>
>
> CDK Tools requires a terminal that allows interactivity of i/o. The full set of requirements is a bit difficult to find a solution for.
> 1) I must be able to get a Process or IProcess object when a command is run
> 2) I must be able to get an event or know when the process terminates
> 3) The terminal or console must be interactive and allow user input when prompted.
> 4) It must behave as in 3) for 'vagrant' commands and any and all associated plugins.
> These three requirements thus far seem impossible to solve. Solutions that have been attempted are:
> 1) Creating a java Process by myself via Runtime.exec. The interactive prompts never arrive and there is no API for Process to know when it is waiting for input.
> 2) Using the external-tools launch configuration. When running a command like mvn, the console that pops up seems to allow input from the user, and functions as expected. However, when running a command such as vagrant, such prompts are not provided. In our usecase, the following behavior is observed:
> a) During vagrant-registration prompts, the console indicates it is not a TTY terminal and cannot allow input
> b) During a landrush prompt for superuser status, no prompt is made, no TTY message is listed, and the process appears to have frozen
> 3) Launching / Opening a tm.terminal view. This solution fails requirements 1 and 2. We are not able to get a Process or an IProcess when a command is launched in a proper interactive terminal. This means we can have no way to know when the process has completed.
> Other options have been explored but ended up at dead ends and not worth mentioning. The real question is why interactive behavior is visible when using external-tools launch config for maven, but is not visible when running vagrant.
> Is this a function of the way the vagrant commands display or prompt for input? Why does vagrant-registration require a TTY terminal, but maven does not? Is this something that can be fixed upstream?
> No other obvious solutions have presented themselves in the past year.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (JBDS-3981) Build a new feature that omits features available from RPM install
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBDS-3981?page=com.atlassian.jira.plugin.... ]
Nick Boldt edited comment on JBDS-3981 at 9/15/16 9:06 AM:
-----------------------------------------------------------
And after installing the 298M rpm, a rebuild yields another 274M rpm. Seems we'll just toggle back and forth. Need to determine which RPM contents is correct. Having diffed two build logs, I've added this new list of blacklisted IUs:
https://github.com/jbdevstudio/jbdevstudio-product/blob/master/rpm/devstu...
Build in progress on wonka and my own machine to see what comes out.
was (Author: nickboldt):
And after installing the 298M rpm, a rebuild yields another 274M rpm. Seems we'll just toggle back and forth. Need to determine which RPM contents is correct. Can probably diff the buildlog.txt files to figure this out...?
> Build a new feature that omits features available from RPM install
> ------------------------------------------------------------------
>
> Key: JBDS-3981
> URL: https://issues.jboss.org/browse/JBDS-3981
> Project: Red Hat JBoss Developer Studio (devstudio)
> Issue Type: Bug
> Components: build, updatesite
> Affects Versions: 10.1.0.AM2
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 10.2.0.AM1
>
> Attachments: .log, feature_dupe_check.sh, IUs-removed-from-rh-eclipse46-devstudio.rpm.txt, IUs-removed-from-rh-eclipse46-devstudio.rpm_more.txt, rh-eclipse46-devstudio.provides.list.01, rh-eclipse46-devstudio.provides.list.02, rheclipse_20160901_0937.log.txt, rheclipse_20160901_0950.log.txt, rheclipse_20160901_1720.log.txt, simpler_install_foorprint_rh-eclipse46-devstudio.rpm.png, simpler_install_foorprint_rh-eclipse46-devstudio.rpm_2.png, simpler_install_foorprint_rh-eclipse46-devstudio.rpm_3.png
>
>
> What we DO need is a feature with fewer dependencies than com.jboss.devstudio.core.feature (eg., which omits pde, emf, xsd, egit...)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months