how can i fix this with Axios, Are there any parameters ?
axios.get('/slug', { params })
Preconnect to required origins
Consider adding preconnect or dns-prefetch resource hints to establish early connections to important third-party origins. Learn more.
why chrome audit declares this opportunity when this url does not exist in the source code
https://immobiliere-essaouira.graines-digitales.fr/
All resource hints can be used only as attributes on a <link> element. You can read about what they do and how for example here
So there is nothing you can do directly in JavaScript (except of course adding the attribute to existing link dynamically based on user action)
If your are requesting something using Axios from domain https://api.my-app.com, just including <link rel="preconnect" href="https://api.my-app.com" /> into your page should be enough...
Related
Link to the HATEOAS This is the link to the Hateoas article (snapshot below) where the identifiers of the resource is part of the URL i.e. 12345. Here the API response has the final API relative URL i.e. /accounts/12345/deposit and the client just needs to hit it.
Link to the Github Users API This is the link to the Github API (snapshot below) where there are lots of placeholders for identifiers. How will clients modify these URLSs and add a value in these placeholders? For example, {/gist_id}, {/other_user}.
Isn't passing the URL with id value instead of placeholder better? Why and when to rely on different clients to add values in these placeholders?
Hypertext as the engine of application state (HATEOAS) is a bit more than just the usage of links. In essence it enforces the interaction model that is used on the Web for two decades quite successfully. On the web a server usually "teaches" clients (browsers) to achieve something via the help of link relations, that can be used to automatically download related resources or give a hint on the reference resource, and Web forms, that define the syntax and semantics of each of the respective supported (input) elements, i.e. a text field, an option element to select one or multiple choices, a drop down or even a slider widget. Based on the affordance of each of the elements a client knows i.e. that a button wants to be clicked or pressed while a text fields wants some user input and stuff or a link annotated with the prefetch link relation name may be downloaded automatically once the current page finished loading as a client might invoke it next or a preload link relation might instruct a user agent to load the referenced resource early in the current page loading process.
The form not only teaches a client about the supported fields a resource has but also about the target URI to send the request to, the HTTP method to use wile sending the request as well as the media-type, which in the case of Web forms is usually implicitly set to application/x-www-form-urlencoded.
In an ideal world a client just uses the information given by the server. Unfortunately, the world isn't perfect and over time people have come up with plenty of other solutions. Among one of them is URI templating that basically allows clients to use a basic URI and fill out certain placeholders with concrete values. As making use of templating requires some knowledge of the URIs intention or the parameters you need to pass, such capabilities make only sense as part of media-type support.
Plain JSON (application/json) has by default no support for URIs whatsoever and as such a user agent receiving a plain JSON payload might not be able to automatically replace a template URI with a concrete one out of the box. JSON Hyper-Schema (application/schema+json) attempts to add link and URI template support to plain JSON payloads. A user client though needs to be hinted with the appropriate media-type in order to automatically resolve the full URI. As such, the user agent also has to support that respective media type otherwise it won't be able to process the document (resolve the template URI to a real URI) successfully.
JSON Hypertext Application Language a.k.a HAL JSON also supports URI templates for links. application/collection+json does support two kinds of templates - query templates and objects-template. The primer one is similar to a URI template by allowing to append certain query parameters to the target URI upon sending the request while the latter one allows to define a whole object that contains all the input elements used to add or edit an item within the collection. JSON-LD does not really support URI templating AFAIK though it uses the concept of a so called context where certain terms can be used to abbreviate URIs. As such something like name can be used within the context for a URI like http://schema.org/name.
As you can hopefully see, the support for URI templating depends on the media-type used for exchanging data. In the case of the outlined github example GET /users/:username this more or less resembles a typical Web API documentation, similar as it is done in a Swagger API documentation, that unfortunately has hardly anything to do with HATEOAS.
For your top example (banking), you should absolutely include the complete URL, with account numbers (IDs), so that the client does not need to translate/substitute anything. This is the most common scenario with HATEOAS. However, GitHub does have those "placeholders" for endpoints that could contain multiple values. You can't include the "following_url" for every user in the response, it's not practical. So you have to determine the "other_user" value another way and make the substitution. Personally, I haven't even had this use case with any of my applications and all of my HATEOAS URLs resemble you first example (though I prefer full URLs not relative). Unless you have specific cases like GitHub does, it's not necessary to use any of these placeholders. Even GitHub only uses that where they could be multiple values. For fixed value URLs, they have the username (like your account number) in the URL ("octocat").
According to me we should not give the direct url in the body
We should always parameterized the api and get details form there.
In simple case if Id of data change than every time data need to update for detail url.
Else if it’s dynamic you will never face this issue.
And this also come under best practices.
I noticed Amazon S3 Redirect rule - GET data is missing but after following the accepted answer my query params still are not being preserved.
I have a site that uses React and React Router, meaning I have several URLs that load identical HTML and JS and then the JS figures out which part of the app to load based on the URL.
For example:
/foo, /bar, /baz all should load index.html, which loads bundle.js. Then bundle.js observes the URL and routes to some React component (also in bundle.js).
However no foo, bar, or baz file exists in S3, only index.html. What I want to do is when I get a 404, redirect to /#!/{URL} (eg. /foo redirects to /#!/foo). This works fine with my redirect rule (below). However, I also want to bring query params with me (eg. /foo?ping=pong redirects to /#!/foo?ping=pong) but instead /foo?ping=pong just redirects to /#!/foo.
Here are my redirect rules:
<RoutingRules>
<RoutingRule>
<Condition>
<HttpErrorCodeReturnedEquals>404</HttpErrorCodeReturnedEquals>
</Condition>
<Redirect>
<Protocol>http</Protocol>
<HostName>www.mydomain.com</HostName>
<ReplaceKeyPrefixWith>#!/</ReplaceKeyPrefixWith>
</Redirect>
</RoutingRule>
</RoutingRules>
Any ideas on some way I can achieve this? Ideally without having to go change something in S3/CloudFront every time I add a new page?
The problem was that I had the origin set up in CloudFront not to forward Query Strings so when S3 got the request it would redirect properly without the query params. You can find this setting in CloudFront > Behaviors > Forward Query Strings.
If you want to have clear urls though you can also check out this trick. You need to setup cloudfront distribution and then alter 404 behaviour in "Error Pages" section of your distribution. That way you can again domain.com/foo/bar links :)
The menus and options in CloudFront/S3 change a lot over time.
Here is a December 2021 solution.
Step 1) Create a "Request" Policy in CloudFront that allows QueryStrings
Note: you might want to also add some Headers like Origin or Access-Control-... headers for CORS.
Step 2) Go to your Distribution > Update the Origin request policy
Step 3) Kick a new Invalidation on /*
Additional Notes for Debuging/Testing
I would recommend testing with curl in terminal rather than a browser to avoid caching and also seeing the details. I do curl -v https://example.com/cb?foo=bar1.
Keep increasing the value of the query string (bar1 in the above example, to bar2, bar3) with every test to make such there is no caching again.
My Problem: I want to introduce a new field in JIRA with status information from external REST Service (response is json).
Plan: Every Jira issue has a input field with some reference string. Behind this field there should be a panel, what should display informations from the external REST call (parsing response JSON is required).
Can someone give me some good info pages, how to tell JIRA to call external REST Service?
If you don't want to build it see:
nFeed
HTTP Feed Custom Field
If you want to build it yourself then start by following this tutorial on Creating a custom field type which is to more or less store a basic String within the database. (This would be the reference string)
You then have two options, the first is within the JiraCustomField class override the getVelocityParameters which was taken from How to call a java method from velocity Atlassian Answers question.
Then create a method (fetchValueFromWebService(String val)) that you would call that would contain code to query the REST Service based off the fields value that would be passed in from the velocity template. (E.g. $instance.fetchValueFromWebService($value))
To perform the actual web service call you can use any library you want, just see the Managing Dependencies documentation so it gets included in the plugin. (For example using the Jira Jersey version see this)
Your other option would be to within the view-basictext.vm have it use javascript and perform an AJAX to the web service by calling a function in your own JS file and dump that into a span that you have defined: (See Including Javascript and CSS resources)
<span id="webServiceValue"></span>
<script type="text/javascript">
fetchValueFromWebService($value);
</script>
You would however need to ensure that the webservice has Cross-origin resource sharing (CORS) enabled if you go the AJAX route.
My main javascript (and so all the static content) is included from https://static.anuary.com. The URL that user is browsing is https://dev.anuary.com/somepath/.
Where does the channel file need to be, dev.anuary.com or static.anuary.com? At the moment it is http://static.anuary.com/channel.html.
I am asking because I am still getting the error that says:
Unsafe JavaScript attempt to access frame with URL
https://www.facebook.com/dialog/oauth?access_token=[..]&api_key=[..]&app_id=[..]&client_id=[..]&display=popup&domain=dev.anuary.com&locale=en_US&origin=1&redirect_uri=http%3A%2F%2Fstatic.ak.facebook.com%2Fconnect%2Fxd_arbiter.php%3Fversion%3D6%23cb%3Df3ac7a0544%26origin%3Dhttp%253A%252F%252Fdev.anuary.com%252Ff373e908a8%26domain%3Ddev.anuary.com%26relation%3Dopener%26frame%3Df312def42c&response_type=token%2Csigned_request&scope=email%2Cuser_birthday%2Cuser_likes%2Cuser_interests%2Cpublish_stream&sdk=joey
from frame with URL
http://dev.anuary.com/658fe23c24564ac978c31d167549c4ce8b36686d65a78ad99bfb38765d46e232/.
Domains, protocols and ports must match.
In response to #dtbarne:
Well, that's the thing – I still don't know, because I've tried bowth ways and any in case it produces the same error:
Unsafe JavaScript attempt to access frame with URL
https://www.facebook.com/dialog/oauth?access_token=[..]&api_key=[..]&app_id=[..]&client_id=[..]&display=popup&domain=dev.anuary.com&locale=en_US&origin=1&redirect_uri=http%3A%2F%2Fstatic.ak.facebook.com%2Fconnect%2Fxd_arbiter.php%3Fversion%3D6%23cb%3Df1ee31b93%26origin%3Dhttp%253A%252F%252Fdev.anuary.com%252Ff9359b2f%26domain%3Ddev.anuary.com%26relation%3Dopener%26frame%3Df18e94f9c4&response_type=token%2Csigned_request&scope=email%2Cuser_birthday%2Cuser_likes%2Cuser_interests%2Cpublish_stream&sdk=joey
from frame with URL
http://dev.anuary.com/658fe23c24564ac978c31d167549c4ce8b36686d65a78ad99bfb38765d46e232/.
Domains, protocols and ports must match.
As you said yourself, this error is not fatal, and is meant is a warning to the user that something fishy might be happening.
Facebook also marked this issue as By Design in their bugs system: Bugs > Unsafe JavaScript attempt to access frame with URL....
Also, there are plenty of threads here on stack overflow about this, for example: Facebook Authentication - Unsafe JavaScript attempt to access frame with URL.
Now that we know that this "error message" is unavoidable, use the channel as you wish, as long as everything works for you.
You don't even need to use the channel, as it states in the documentation:
The channelUrl parameter is optional, but recommended. Providing a
channel file can help address three specific known issues. First,
pages that include code to communicate across frames may cause Social
Plugins to show up as blank without a channelUrl. Second, if no
channelUrl is provided and a page includes auto-playing audio or
video, the user may hear two streams of audio because the page has
been loaded a second time in the background for cross domain
communication. Third, a channel file will prevent inclusion of extra
hits in your server-side logs. If you do not specify a channelUrl, you
can remove page views containing fb_xd_bust or fb_xd_fragment
parameters from your logs to ensure proper counts.
But it also states that:
The channel file addresses some issues with cross domain communication
in certain browsers.
So it's up to you to decide.
I personally recommend to use the channel and to serve the file from your regular server and not from the static servers.
You should however set the output to have a long caching expiration date so that your server won't get a lot of requests for this file, as they mention in the JS SDK documentation page:
<?php
$cache_expire = 60*60*24*365;
header("Pragma: public");
header("Cache-Control: max-age=".$cache_expire);
header('Expires: ' . gmdate('D, d M Y H:i:s', time()+$cache_expire) . ' GMT');
?>
<script src="//connect.facebook.net/en_US/all.js"></script>
(php example, but can be done with any language).
Hope this answers clarifies things for you.
Sounds like you know the answer already. It has to be on dev.anuary.com. The purpose is to allow for communication between FB and the URL the user accessed.
The channel file should be places on the server / address the user visits, as the channel file is used to fix some cross-site javascript errors. If the user is always accessing your website using HTTPS, then you should reference the channel file using HTTPS as well as any other content.
The channel file itself should stay as <script src="//connect.[..], but make sure all your static content and JS Includes all have https in them.
I am trying to figure out how to handle this error.
A potentially dangerous Request.Form value was detected from the client
The error occurs when a user enters in html or xml tags( <p> or <HeyImXML>) and tries to submit a form. The input is not supposed to contain any sort of markup at all, just plain text.
I am using model binding validation in ASP.NET MVC 2.0 along with Html.EnableClientValidation. This works fine as long as there is no markup entered.
What is the best approach on how to avoid this error message?
My guess is to write a new validation class which checks for this kind of markup?
I want to catch the error in this specific instance. To clarify there is an area with a form for siteadmins that can enter markup and there is a normal users area where they can not enter markup. However this error page appears when a normal users enters markup. My question is, how do I handle this to prevent the site from crashing and showing the error page. I want to display a cleaner error.
MVC will automatically protect your application from some html injection and cross-site scripting (XSS) attacks. This is why you will get the "A potentially dangerous Request.Form value was detected from the client (...)" by default when attempting to post html/javascript.
However, we may sometimes want to allow our users to post html. You might just want to allow users to use characters such as "›", or it might be because your implementing blog functionality and want to support tags like ‹h1›, ‹div›, etc. This can easily be accomplished with MVC by disabling request validation.
Add [ValidateInput(false)] attribute to the action method in the controller you are calling. This will disable request validation for the entire model on the specific action.
Another way is to add the [AllowHtml] attribute to the property which requires html in your model.
These two attributes will only allow html/javascript to GET IN to your application, but MVC will still output them safely by using html encoding. If you want to output it like html, you can use the #Html.Raw(#Model.Content). But use this with caution, since this will open your application to cross-site scripting attacks (XSS)!
i found this solution from some one's blog
also see below code for your solution
you can handle errors within your application in the following way
1. Setting the CustomErros mode section in your Web.Config file of your application
This the lists of options the mode attribute can accept.
RemoteOnly: Generic error pages are shown for remote users. Rich error pages are shown for local requests (requests that are made from the current computer). This is the default setting.
Off: Rich error pages are shown for all users, regardless of the source of the request. This setting is helpful in many development scenarios but should not be used in a deployed application.
On: Generic error pages are shown for all users, regardless of the source of the request. This is the most secure option.
<System.Web>
//map all the erros presented in the application to the error.aspx webpage
<customErrors mode="RemoteOnly" defaultRedirect ="~/error.aspx" />
<System.Web>
2. throught Global.asax file in the Application_Error function
//handle all the errors presented in the application
void Application_Error(object sender, EventArgs e){
Server.Tranfer("error.aspx");
}
I hope this works for you.
from stackoverflow solution
This was introduced early on in ASP.Net to try to help prevent script injection attacks. It isn't unique to MVC.
If you don't want this feature, you can turn it off and write your own.
To disable request validation on a page, set the validateRequest attribute of the Page directive to false:
<%# Page validateRequest="false" %>
To disable request validation for your application, modify Web.config - set the validateRequest attribute of the <pages /> section to false:
<configuration>
<system.web>
<pages validateRequest="false" />
</system.web>
</configuration>