what is the difference between a Spring Security intercept-url pattern with path/** or path/*
I've seen some Spring security configurations that have the below, but I don't understand the /* vs /**
The /** vs. /* is a pretty common thing in frameworks nowadays, and is generally referred to as Apache Ant Pathing or something similar. Basically, the difference between the 2 is that /** matches the entire directory tree, including subdirectories, where as /* only matches at the level it's specified at.
For example, suppose you had the following files
Main.java
directory/Main.java
Then
/*.java
Would match Main.java, but not directory/Main.java, whereas
/**/*.java
would match both.
Obviously the principles applies exactly the same for urls in Spring Security, just seemed to a bit easier to illustrate it via file names in this case.
Related
I have rule A implemented with a macro that uses declare_directory to produce a set of files:
output = ctx.actions.declare_directory("selected")
Names of those files are not known in advance. The implementation returns the directory created by declare_directory with the following:
return DefaultInfo(
files = depset([output]),
)
Rule A is included in "srcs" attribute of rule B. Rule B is also implemented with a macro. Unfortunately the list of files passed to B implementation through "srcs" attribute only contains the "selected" directory created by rule A instead of files residing in that directory.
I know that Args class supports expansion of directories so I could pass names of all files in "selected" directory to a single action. What I need, however, is a separate action for every individual file for parallelism and caching. What is the best way to achieve that?
This is one of the intended use cases of directory outputs (called TreeArtifacts in the implementation), and it's implemented using ActionTemplate:
https://github.com/bazelbuild/bazel/blob/c2100ad420618bb53754508da806b5624209d9be/src/main/java/com/google/devtools/build/lib/actions/ActionTemplate.java#L24-L57
However, this is not exposed to Starlark, and has only a couple usages currently, in the Android rules AndroidBinary.java and C++ rules CcCompilationHelper.java. The Android rules and C++ rules are going to be migrated over to Starlark, so this functionality might eventually be made available in Starlark, but I'm not sure of any concrete timelines. It would probably be good to file a feature request on Github.
I am writing a custom rule that takes inputs from cc_library, cc_binary, apple_static_library, and a few other platform-specific rules. I'd like to view each API given to me via referencing ctx.attr.foo inside the custom rule's implementation function.
There is a list of providers here https://docs.bazel.build/versions/master/skylark/lib/skylark-provider.html but it doesn't say which rules are using them.
Is there a best practice for viewing what these rules are providing me, or does it require going through the source for each one?
This is how you get all providers and output groups from a target:
bazel cquery my_target --output=starlark --starlark:expr="providers(target)"
You can get a list of providers for a given target with dir. Something like this is helpful for debugging:
def _print_attrs_impl(ctx):
for target in ctx.attr.targets:
print('%s: %s' % (target.label, dir(target)))
Printing from inside a rule you're developing is often helpful too, to verify targets are actually what you expect them to be.
You can also apply dir to the providers themselves, to see what fields they have.
My Grails (2.4.2) app was created with a bunch of "default/standard" resource bundles:
myapp/
grails-app/
i18n/
messages.properties
messages_fr.properties
I would now like to create my own "custom" resource bundle, that is, define properties in a file outside of these standard messages*.properties files that myapp was created with.
According to the i18n documentation, all bundles need to be prefixed with messages and suffixed .properties. So I added two new props files, one for English and one for French:
myapp/
grails-app/
i18n/
messages.properties
messages_fr.properties
messages_myapp.properties
messages_myapp_fr.properties
For one, I'm not 100% sure I'm interpreting the docs correctly. So if anything about my 2 new props files jumps out at you as being incorrect, please start by letting me know!
Having said that, in all the example from those docs, I don't see where you specify the bundle to use. All of the examples look like this:
<g:message code="fizz.buzz.foo" />
But what if I have a fizz.buzz.foo property defined in both messages_blah.properties and messages_bar.properties?
So I ask: How do I add my own custom resource bundles, and how do I properly refer to them from inside a GSP?
To answer your question you have to understand what Grails (well, Spring really) is doing to accomplish this.
You are on the right path with the multiple files. What you have outlined there matches the documentation and will work.
However, under the covers what is really being done is they are being combined into a single bundle (per language). So there is no need to tell Grails/Spring which bundle to use.
Finally, what happens when the same key is defined multiple times? The first one matched wins. I seem to recall that the order in which the bundles are combined is in file name order, though you should be able to test this pretty quickly.
Hope this helps, and best of luck!
Intro:
I'm trying out LESS in an asp.net mvc environment.
I use dotless for server side processing (and I wouldn't want to use client side processing especially afer publishing the complete project).
I have to apply a design where there are different color schemes depending on different things (e.g. time of the day).
Less felt very powerful in this case as designing a parameterized css and only changing like 10 variables at the beginning of the file for every theme was really uplifting.
Problem:
But I would need to somehow change the color themes from an outside parameter.
Ideas:
First I thought that an URL parameter like style.less?theme=fuschia would be good, but I found no way to parse something like this.
Then I thought that making a very short blue.less, green.less, orange.less consisting only declared color variables, and including the main.less in every one of them would be a solid solution.
I had no chance to try out the second solution, but I thought this would be a good time to ask for advice on the most robust way of doing this.
The problem again is: I want to control some things in my less file from the outside.
Yes you can (because I implemented that feature for exactly that reason).
Dotless supports parameters from the outside via the querystring parameter.
<link rel="stylesheet" href="style.less?foo=bar" />
Will let you use the following less:
#foo = bar;
The parameter injection code is very simple. it just prepends the variable declarations to your normal less file, so anything that comes as a querystring parameter will follow the above syntax.
The code in question is very simple: https://github.com/dotless/dotless/blob/master/src/dotless.Core/Engine/ParameterDecorator.cs
AFAIK, you cannot pass parameters for dotnetless to use to do the compile.
As a suggestion, why not just call different less files? This would be fairly easy to do by using a Viewbag property.
To make the different less ones, You first create a less file with each set of colors in them. Then you import your base css file. dotnetless will merge the color definations in the parent file with the usages in the base file. So you have something like -
#baseGray: #ddd;
#baseGrayDark: darken(#baseGray, 15%);
#baseGrayLight: lighten(#baseGray, 10%);
#import "baseCss.less";
I just tested this on and MVC3 project and it works.
We have a requirement that every piece of code that makes it into production will be reviewed by a senior developer.
The way I have envisioned this working is by a naming convention for branches that regular developers cannot check code into.
Following the SVN recomended directory structure this translates into something like.
[project-name]/trunk/
[project-name]/branches/
[project-name]/branches/development-01
[project-name]/branches/development-02
[project-name]/branches/task-increasefontsize
[project-name]/branches/release-01
[project-name]/branches/release-02
[project-name]/tags/
So in the authz file I would like to have something like the following
[/]
#developers = rw
[/*/branches/release-*]
#developers = r
#senior_developers = rw
However I can't find any evidence that SVN supports * (or any other wildcard character).
Is such a thing possible or do I need a pre-commit hook?
It is possible to do a directory structure of
[project-name]/trunk/
[project-name]/branches/development-01
[project-name]/branches/development-02
[project-name]/branches/task-increasefontsize
[project-name]/branches/release-01
[project-name]/branches/release-02
[project-name]/tags/
[project-name]/releases/
and deny access to releases but that still leaves you having to do one denial listing per project and worse its not adhering to the SVN standard project structure.
It is not possible to have wildcards as you like to use them. For this purpose you should take a look at svnperm.py script (just google for it) it will match exactly this purpose.