Is there a way to implement control statement with Spring Security taglibs?
Currently we can only check if a user has a role...
<security:authorize access="hasRole('ROLE_ADMIN')">
// display something
</security:authorize>
How about else?
The question is old, but anyway..
You can store the result of tag evaluation into variable (at least at version 3.1) and then use it within standard if/else construction. I think this is more useful solution than previous one.
<security:authorize access="hasRole('ROLE_ADMIN')" var="isAdmin" />
<c:choose>
<c:when test="${isAdmin}">superuser</c:when>
<c:otherwise>ordinary user</c:otherwise>
</c:choose>
If you missed the comment of the accepted answer. Here is how to make a control statement out of <security:authorize>
<security:authorize access="hasRole('ROLE_ADMIN')">
// IF -- display something
</security:authorize>
<security:authorize access="!hasRole('ROLE_ADMIN')">
// ELSE -- display something
</security:authorize>
Notice the ! not statement in else condition
credits to #Blake
Value of the access attribute is a SpEL expression, evaluated against WebSecurityExpressionRoot, so you can use all its methods and all SpEL syntax.
Also you can customize creation of the evaluation context by declaring a custom WebSecurityExpressionHandler as a bean (then you can add your own methods and variables).
Related
I'm working on a simple JIRA Server plugin that will prevent a transition from occurring if a certain custom field has not been set. I have created a new workflow validator with atlas-create-jira-plugin-module and tailored the validate function to fit my needs. Strangely, when I add this new validator to a transition via the workflow editor, it appears in the list of validations with the wrong description. It is showing the description from the default condition, "Only users with Resolve Issues" permission can execute this transition".
I've been following along with this tutorial: https://developer.atlassian.com/server/jira/platform/creating-workflow-extensions/
I also came across this similar tutorial: https://www.j-tricks.com/tutorials/workflow-validator
In my atlassian-plugin.xml I made sure to define a "view" velocity resource:
<workflow-validator key="custom-field-is-set-validator" name="Custom Field Is Set Validator" i18n-name-key="custom-field-is-set-validator.name" class="com.ngc.jira.plugins.workflow.CustomFieldIsSetValidatorFactory">
<description key="custom-field-is-set-validator.description">Validation to require that a custom field be given a value.</description>
<validator-class>com.ngc.jira.plugins.workflow.CustomFieldIsSetValidator</validator-class>
<resource type="velocity" name="view" location="templates/validators/custom-field-is-set-validator.vm"/>
<resource type="velocity" name="input-parameters" location="templates/validators/custom-field-is-set-validator-input.vm"/>
<resource type="velocity" name="edit-parameters" location="templates/validators/custom-field-is-set-validator-input.vm"/>
</workflow-validator>
And the contents of custom-field-is-set-validator.vm are as follows:
Only if the custom field <strong>$field</strong> has be set.
As a sanity check, I created a workflow condition and applied my velocity (vm) resource as the view template for it. It shows up correctly within this context!
However, when I try to use the same velocity resource for my workflow validator, the admin page still displays the validator as "Only users with Resolve Issues permission can execute this transition" instead of using my description.
What am I missing? Thanks!
Screenshot showing the built-in condition
Screenshot showing my validator that is wrongly appearing as the same condition
I wrote an O'Reilly book Practical Jira Plugins back in 2011 that has a validator example. The source for this is at https://bitbucket.org/mdoar/practical-jira-plugins/src/default/ (and the book is Out There).
But frankly these days I'd use ScriptRunner, JMWE or other plugins that let you write custom workflow things. But don't let that stop you learning it! Good luck
It turns out, I had copied/pasted a piece of code from my workflow condition that needed to be tweaked for a workflow validator. I was trying to cast to a ConditionDescriptor when I should have been casting to a ValidatorDescriptor:
Bad:
if (!(descriptor instanceof ConditionDescriptor)) {
throw new IllegalArgumentException("Descriptor must be a ConditionDescriptor.");
}
ConditionDescriptor conditionDescriptor = (ConditionDescriptor) descriptor;
Good:
if (!(descriptor instanceof ValidatorDescriptor)) {
throw new IllegalArgumentException("Descriptor must be a ValidatorDescriptor.");
}
ValidatorDescriptor validatorDescriptor = (ValidatorDescriptor) descriptor;
Pretty neat that instead of completely breaking my plugin, it ended up displaying a different description altogether. ;)
Suppose I want to create 3 custom release variables on TFS.
variable1
variable2
variable3
can i specify somewhere that to enter a variable3, user must enter variable1 and 2?
i cant prepopulate them myself because the input is quiet dynamic.
for now i am using an ugly method like this:
variable2_MUST_ENTER_VARIABLE1_FIRST
variable3_MUST_ENTER_VARIABLE1_AND_VARIABLE2_FIRST
i wish there is a way to specify some sort of note next to the textbox or something :/
Is it possible to have a condition for a custom variable?
The short answer is yes. But I could not quite confirm if it is what you want.
To set a condition for a custom variable, we could enable a custom condition on the task in the pipeline:
Conditions:
Conditions are written as expressions. The agent evaluates the
expression beginning with the innermost function and works its way
out. The final result is a boolean value that determines if the task,
job, or stage should run or not. See the expressions topic for a full
guide to the syntax.
example:
and(succeeded(), ne(variables['variable1'], ''))
But, this condition for a custom variable will be applied at build/release time instead of entering the value of variable.
i wish there is a way to specify some sort of note next to the textbox
or something
If you want to set the condition for a custom variable on the UI, I am afraid there is no such better way than you are using at this moment. You can add your request for this feature on our UserVoice site (https://developercommunity.visualstudio.com/content/idea/post.html?space=21 ), which is our main forum for product suggestions. Thank you for helping us build a better Azure DevOps.
Hope this helps.
The current implementation of a CCDA generator I'm working on, prints a message on a <name> tag (in header sections, where no <text> is available) when something's name is not found:
<name>No information</name>
I know the right way to express not found information is through the #nullFlavor attribute:
<name nullFlavor="NI" />
But right now there is a component on the application that reads the value on the tag and shows it in a human-readable view of the CCDA document. If I use #nullflavor only, the field that shows such name will be empty, instead of "No information".
In order to avoid changing such component, I was thinking on adding the #nullFlavor attribute but still letting the message there:
<name nullFlavor="NI">No information</name>
I know this is syntactically correct, because I've tested it with the reference validator and it passes. My question is: from a semantic point of view, is it valid?
Yes it's valid. The particular specification in question - the v3 abstract data types, simple says:
invariant(ST x) where x.nonNull {
x.headCharacter.notEmpty;
};
So if there's no nullFlavor, there must be some content. But the reverse rule is not applied; there can be content if there's a nullFlavor
Although it is not restricted, my point of view is that it is not a good strategy. I understand that you have a restriction regarding this component but, when you are building a CDA, it is important to keep in mind that it is something to be shared with everyone, and I would never expect to find content inside a nullFlavor attributed element.
Using I am trying to paint on my jsp some comboboxes which must be connected with variable in my Action class. Because of amount of my comboboxes are dynamic calculated I cann't create exact amount of variables in Action class. So I was trying to apply principle of index to my comboboxes. But my Action class gets misunderstood Object value.
<s:iterator value="question.answers" id="entry" status="status">
<s:property value="text"/>
<s:combobox list = "question.answers" listValue="rightText" listKey="rightText" name="%{'chosenComboOption['+#status.count+']'}" emptyOption="false"/>
<br />
</s:iterator>
Please help me to get chosen values from my comboboxes!
A couple of things jump out at me. First of all, you don't want to use "status.count", because that returns the total number of items in the list, not the current iteration index. Instead you would want to use "status.index". Second, I think your syntax is incorrect in the index selection. Trying to do things manually like this is a sort of black magic that you have to tweak to try to get just right.
In a project that I was working on recently, I had to do something similar to this. Not sure if this exact syntax will work for you or not, but it is worth a shot. Try to change:
name="%{'chosenComboOption['+#status.count+']'}"
to this:
name="chosenComboOption[%{#status.index}]"
Tagsoup is interfering with input and formatting it incorrectly. For instance when we have the following markup
Text outside anchor
It is formatted as follows
Text outside anchor
This is a simple example but we have other issues as well. So we made tagsoup cleanup/formatting optional by adding an extra attribute to textarea control.
Here is the diff(https://github.com/binnyg/orbeon-forms/commit/044c29e32ce36e5b391abfc782ee44f0354bddd3).
Textarea would now look like this
<textarea skip-cleanmarkup="true" mediatype="text/html" />
Two questions
Is this the right approach?
If I provide a patch can it make it to orbeon codebase?
Thanks
BinnyG
Erik, Alex, et al
I think there are two questions here:
The first Concern is a question of Tag Soup and the clean up that happens OOTB: Empty tags are converted to singleton tags which when consumed/sent to the client browser as markup gets "fixed" by browsers like firefox but because of the loss of precision they do the wrong thing.
Turning off this clean up helps in this case but for this issue alone is not really the right answer because we it takes away a security feature and a well-formed markup feature... so there may need to be some adjustment to the handling of at least certain empty tags (other than turning them in to invalid singleton tags.)
All this brings us to the second concern which is do we always want those features in play? Our use-case says no. We want the user to be able to spit out whatever markup they want, invalid or not. We're not putting the form in an app that needs to protect the user from cross script coding, we're building a tool that lets users edit web pages -- hence we have turned off the clean-up.
But turning off cleanup wholesale? Well it's important that we can do it if that's what our usecase calls for but the implementation we have is all or nothing. It would be nice to be able to define strategies for cleanup. Make that function plug-able. For example:
* In the XML Config of the system define a "map" of config names to class names which implement the a given strategy. In the XForm Def the author would specify the name from the map.
If TagSoup transforms:
Text outside anchor
Into:
Text outside anchor
Wouldn't that be bug in TagSoup? If that was the case, then I'd say that it is better to fix this issue rather than disable TagSoup. But, it isn't a bug in TagSoup; here is what seems to be happening. Say the browsers sends the following to the client:
<a shape="rect"></a>After<br clear="none">
This goes through TagSoup, the result goes through the XSLT clean-up code, and the following is sent to the browser:
<a shape="rect"/>After<br clear="none"/>
The issue is on the browser, which transforms this into:
<a shape="rect">After</a><br clear="none"/>
The problem is that we serialize this as XML with Dom4jUtils.domToString(cleanedDocument), while it would be more prudent to serialize it as HTML. Here we could use the Saxon serializer. It is also used from HTMLSerializer. Maybe you can try changing this code to use it instead of using Dom4jUtils.domToString(). You'll let us know what you find when a get a chance to do that.
Binesh and I agree, if there is a bug it would be a good idea to address the issue closer to the root. But I think the specific issue he is only part of the matter.
We're thinking it would be best to have some kind of name-to-strategy mapping so that RTEs can call in the server-side processing that is right for them or the default if it's not specified.