Configuration about a single route for ajax call: getamministrazioni.json
I tried to change configuration site as follow:
...
routeEnhancers:
News:
type: Extbase
extension: News
plugin: Pi1
routes:
-
routePath: '/{news-title}'
_controller: 'News::detail'
_arguments:
news-title: news
aspects:
news-title:
type: PersistedAliasMapper
tableName: tx_news_domain_model_news
routeFieldName: path_segment
PageTypeSuffix:
type: PageType
default: .html
map:
.html: 0
getamministrazioni.json: 1035343
errorHandling: { }
routes: { }
...
And in setup.typoscript i have:
GetAmministrazioni = PAGE
GetAmministrazioni {
typeNum = 1035343
config {
disableAllHeaderCode = 1
debug = 0
no_cache = 1
additionalHeaders {
10 {
header = Content-Type: application/json
replace = 1
}
}
}
10 < tt_content.list.20.my_controller_getamministrazioni
}
It works but for all pages.
/home/getamministrazioni.json
/page1/getamministrazioni.json
etc.. etc..
I want a single route from root '/getamministrazioni.json
how i can do that?
There is a possibility to limit the routing to specific page ids:
limitToPages: 1
But this will limit your whole mapping configuration to page id 1, also the .html suffix (which you don't want to, I guess).
Unfortunately, it is currently not possible to create multiple Route Enhancers with the same name, like in the following, non-working example:
PageTypeSuffix:
type: PageType
map:
.html: 0
PageTypeSuffix:
type: PageType
limitToPages: 1
map:
sitemap.xml: 1533906435
Two possible workarounds:
Create your own RouteEnhancer, which just extends TYPO3\CMS\Core\Routing\Enhancer\PageTypeDecorator to allow a different name (see custom enhancers)
Redirect your json page type to an error page, if page id is not 0 (no routing neccessary, as TypoScript avoids delivering of this page type)
[getTSFE().id != 1]
seo_sitemap.config {
additionalHeaders.10 {
header = Location: /error.html
}
}
[END]
I found another solution. I create a plugin and i use controller to print json and i 'return' false. In template setup strip all html and i change header content type. So in every page i insert a a plugin as content that print the json
Related
in the TYPO3 Docu we can read the example: Using Site Configuration in TypoScript
Site-Config Yaml to typoscript.
But this Code-Example work only in the "page" corner.
page.10 = TEXT
page.10.data = site:base
page.10.wrap = This is your base URL: |
And i use this here in the FLUIDTEMPLATE:
page {
10 {
variables {
# BaseURL
siteConfigBase = TEXT
siteConfigBase {
data = site:base
}
}
}
This works fine, in the f.debug is the right output siteConfigBase = https://example.org
How can i pass the values to config.baseURL ?
config.baseURL supports only strings but not stdWrap.
But you can use a condition to get what you want:
[site("identifier") == "foo"]
config.baseURL = foo
[global]
The identifier is the name of the folder of your site configuration.
Trying to setup a Cloudfront behaviour to use a Lambda function url with code like this:
this.distribution = new Distribution(this, id + "Distro", {
comment: id + "Distro",
defaultBehavior: {
origin: new S3Origin(s3Site),
viewerProtocolPolicy: ViewerProtocolPolicy.REDIRECT_TO_HTTPS,
},
additionalBehaviors: {
[`api-prd-v2/*`]: {
compress: true,
originRequestPolicy: originRequestPolicy,
origin: new HttpOrigin(functionUrl.url, {
protocolPolicy: OriginProtocolPolicy.HTTPS_ONLY,
originSslProtocols: [OriginSslPolicy.TLS_V1_2],
}),
allowedMethods: AllowedMethods.ALLOW_ALL,
viewerProtocolPolicy: ViewerProtocolPolicy.HTTPS_ONLY,
cachePolicy: apiCachePolicy,
},
The functionUrl object is created in a different stack and passed in to the cloudformation stack, the definition looks like:
this.functionUrl = new FunctionUrl(this, 'LambdaApiUrl', {
function: this.lambdaFunction,
authType: FunctionUrlAuthType.NONE,
cors: {
allowedOrigins: ["*"],
allowedMethods: [HttpMethod.GET, HttpMethod.POST],
allowCredentials: true,
maxAge: Duration.minutes(1)
}
});
The above code fails because "The parameter origin name cannot contain a colon".
Presumably, this is because functionUrl.url evaluates to something like https://xxx.lambda-url.ap-southeast-2.on.aws/ (note the https://) whereas the HttpOrigin parameter should just be the domain name like xxx.lambda-url.ap-southeast-2.on.aws.
I can't just write code to hack the url up though (i.e. functionUrl.url.replace("https://", "")) because when my code executes, the value or the url property is a token like ${Token[TOKEN.350]}.
The function url is working properly: if I hard-code the HttpOrigin to the function url's value (i.e. like xxx.lambda-url.ap-southeast-2.on.aws) - it works fine.
How do I use CDK code to setup the reference from Cloudfront to the function url?
I'm using aws-cdk version 2.21.1.
There is an open issue to add support: https://github.com/aws/aws-cdk/issues/20090
Use CloudFormation Intrinsic Functions to parse the url string:
cdk.Fn.select(2, cdk.Fn.split('/', functionUrl.url));
// -> 7w3ryzihloepxxxxxxxapzpagi0ojzwo.lambda-url.us-east-1.on.aws
It looks as though if you put your jsx files in the 'pages' folder of most gatsby starters, the urls follow the directory structure out of the box, so you can implement whatever urls you need (http://blah.com/foo/post1, http://blah.com/bar/post2) just by nesting folders in the source tree (pages/foo/post.jsx, pages/bar/post2.jsx).
The issue
I used the gatsby advanced starter (https://github.com/Vagr9K/gatsby-advanced-starter). It puts all content files not in pages/, but in a top-level content/ folder and I can't figure out the wiring to replicate foo/xxx, bar/xxx urls even after creating content/foo/post1.md, content/bar/post2.md folders.
It does have a siteconfig.js that sets a single path prefix, but I want two different prefixes for the 2 different sections of the site, so I just set it to "/" for now (builds seem to ignore whatever value I set for this config param anyway, so... shrug).
What I tried
I tried adding path to the frontmatter of the .md files and set it to the parent foldername. This was completely ignored (in any case I don't think that's what I want... I'd like to keep the generated slug as part of the url).
Separated use of gatsby-source-filesystem one for each subfolder hoping it would change graphql graph to recognize 2 separate data sources but it made no difference.
What am I doing wrong?
It looks as though if you put your jsx files in the 'pages' folder of most gatsby starters, the urls follow the directory structure out of the box [...]
That's not specific to Gatsby starters, that's Gatsby's default behaviour. Every js/jsx file in src/pages will be a page.
but in a top-level content/ folder
It still has the src/pages folder for normal pages. But the content folder holds the files will be transformed with the src/templates in gatsby-node.js to pages. Or in other words: The contents of the content folder get programmatically created with the defined template in gatsby-node.js (and the template lies in src/templates).
The path/url get's defined in the createPage function here: gatsby-nodeL144. This line is referencing the edge.node.fields.slug which gets queried in the GraphQL above here. The field gets added in the onCreateNode function. More specificially the slug field in the onCreateNodeField function. There you see that it gets passed a slug that gets defined above.
Create two folders in your src/content folder, e.g. blog and projects. Make sure that you have both of them defined in your gatsby-config.js:
{
resolve: 'gatsby-source-filesystem',
options: {
name: 'blog',
path: `${__dirname}/content/blog`,
},
},
{
resolve: 'gatsby-source-filesystem',
options: {
name: 'projects',
path: `${__dirname}/content/projects`,
},
},
In your gatsby-node.js add after the fileNode definition the line:
const pathPrefix = fileNode.sourceInstanceName
The sourceInstanceName is that what we defined as the name in gatsby-config entries.
Then you can alter the line to:
createNodeField({ node, name: "slug", value: `/${pathPrefix}${slug}` });
createNodeField({ node, name: 'sourceInstanceName', value: pathPrefix });
The second line is helpful if you then want to query only for one of the two folders, e.g.:
export const pageQuery = graphql`
query BlogQuery {
allMarkdownRemark(filter: { fields: { sourceInstanceName: { eq: "blog } } }
) {
edges {
node {
... etc
}
}
}
}
`
My server-side policy signing code is failing on this line:
credentialCondition = conditions[i]["x-amz-credential"];
(Note that this code is taken from the Node example authored by the FineUploader maintainer. I have only changed it by forcing it to use version 4 signing without checking for a version parameter.)
So it's looking for an x-amz-credential parameter in the request body, among the other conditions, but it isn't there. I checked the request in the dev tools and the conditions look like this:
0: {acl: "private"}
1: {bucket: "menu-translator"}
2: {Content-Type: "image/jpeg"}
3: {success_action_status: "200"}
4: {key: "4cb34913-f9dc-40db-aecc-a9fdf518a334.jpg"}
5: {x-amz-meta-qqfilename: "f86d03fb-1b62-4073-9458-17e1dfd8b3ae.jpg"}
As you can see, no credentials. Here is my client-side options code:
var uploader = new qq.s3.FineUploader({
debug: true,
element: document.getElementById('uploader'),
request: {
endpoint: 'menu-translator.s3.amazonaws.com',
accessKey: 'mykey'
},
signature: {
endpoint: '/s3signaturehandler'
},
iframeSupport: {
localBlankPagePath: '/views/blankForIE9Support.html'
},
cors: {
expected: true,
sendCredentials: true
},
uploadSuccess: {
endpoint: 'success.html'
}
});
What am I missing here?
I fixed this by altering my options code in one small way:
signature: {
endpoint: '/s3signaturehandler',
version: 4
},
I specified version: 4 in the signature section. Not that this is documented anywhere, but apparently the client-side code uses this as a flag for whether or not to send along the key information needed by the server.
We have a asp.net web api application which uses swagger/swashbuckle for it's api documentation. The api is secured by azure AD using oauth/openid-connect. The configuration for swagger is done in code:
var oauthParams = new Dictionary<string, string>
{
{ "resource", "https://blahblahblah/someId" }
};
GlobalConfiguration.Configuration
.EnableSwagger(c =>
{
c.SingleApiVersion(Version, Name);
c.UseFullTypeNameInSchemaIds();
c.OAuth2("oauth2")
.Description("OAuth2 Implicit Grant")
.Flow("implicit")
.AuthorizationUrl(
"https://login.microsoftonline.com/te/ourtenant/ourcustompolicy/oauth2/authorize")
.TokenUrl(
"https://login.microsoftonline.com/te/ourtenant/ourcustompolicy/oauth2/token");
c.OperationFilter<AssignOAuth2SecurityRequirements>();
})
.EnableSwaggerUi(c =>
{
c.EnableOAuth2Support(_applicationId, null, "http://localhost:49919/swagger/ui/o2c-html", "Swagger", " ", oauthParams);
c.BooleanValues(new[] { "0", "1" });
c.DisableValidator();
c.DocExpansion(DocExpansion.List);
});
When swashbuckle constructs the auth url for login, it automatically adds:
&scope=
However I need this to be:
&scope=openid
I have tried adding this:
var oauthParams = new Dictionary<string, string>
{
{ "resource", "https://blahblahblah/someId" },
{ "scope", "openid" }
};
But this then adds:
&scope=&someotherparam=someothervalue&scope=openid
Any ideas how to add
&scope=openid
To the auth url that swashbuckle constructs?
Many thanks
So, found out what the issue was, the offending code can be found here:
https://github.com/swagger-api/swagger-ui/blob/2.x/dist/lib/swagger-oauth.js
These js files are from a git submodule that references the old version of the UI.
I can see on lines 154-158 we have this code:
url += '&redirect_uri=' + encodeURIComponent(redirectUrl);
url += '&realm=' + encodeURIComponent(realm);
url += '&client_id=' + encodeURIComponent(clientId);
url += '&scope=' + encodeURIComponent(scopes.join(scopeSeparator));
url += '&state=' + encodeURIComponent(state);
It basically adds scopes regardless of whether there are scopes or not. This means you cannot add scopes in the additionalQueryParams dictionary that gets sent into EnableOAuth2Support as you will get a url that contains 2 scope query params i.e.
&scope=&otherparam=otherparamvalue&scope=openid
A simple length check around the scopes would fix it.
I ended up removing swashbuckle from the web api project and added a different nuget package called swagger-net, found here:
https://www.nuget.org/packages/Swagger-Net/
This is actively maintained and it resolved the issue and uses a newer version of the swagger ui. The configuration remained exactly the same, the only thing you need to change is your reply url which is now:
http://your-url/swagger/ui/oauth2-redirect-html