You can give someone an url with get:
http://myserver.com/?var=val
But what to do with POST method ? I know that the program I put url into must support this, I do not know any browser that can (maybe with plugin possible), but is there widely accepted syntax to do it, for example I came up with this:
http://myserver.com/<var=val>
or maybe:
http://myserver.com/??var=val
http://myserver.com/?!var=val
http://myserver.com/!!var=val
http://myserver.com/!var=val
etc...
I'm writing a tool to do it , and I wonder if I must think on my own just like first guy who created e-mail and out of the air conceived # character since it was rarely used then...
The idea is that some services use post data and there is no way to send someone link to resource there. And yes I know that when there is post data that resource is not meant to be such easy passeable to people... but wait since when author of a website has to have power over what I can and can't do with his service.
You'd better introduce a separate argument for passing POST data to your tool. Mixing it together with URL would just cause confusion among your users. Remember that POST data be quite large, so you'd end up introducing features like loading POST data (or a value of an individual variable) from a file anyway.
Related
Which URL structure should I use for my Web-app?
Clean URLs like this
http://dashboard.company.com/sales/john-doe/2017/32
or with URL parameters?
http://dashboard.company.com/sales?person=john.doe&year=2017&week=32
Are there any guidelines for this?
Edit to explain my question better From the user perspective, the two ways are identical in ways of sharing the url. For the programming part they are not, I use Flask. I want know if there's a standard way of handling it, what is the better way?
Background
I am developing a Sales Dashboard for internal use at my company. It display the sales of every sales person. I want to make the reports shareable so that my colleagues can send their own page for a certain weeknumber with each other, or whatever. Or the boss can easily get the page for a meeting with the sales person.
No SEO
Just to stress this point. I don't need clean URLs for SEO.
It doesn't matter at all, by adding the parameters as GET or POST they will be visible but if you use a framework for your app, you should use clean as possible because the parameters to the controllers must be specific and not by data. Otherwise if is not a big project you can use like that but you need to make sure that soon you wont have something like lang?en or something which will be as main parameter. It's up to you, read GET x POST differences and you'll figure it out better.
I know this is probably a long-shot, but is it possible to use Siesta with a completely non-RESTful API? The API I have to work with (and is not in my control so sadly cannot change) requires every request to be a POST request regardless of whether it is purely retrieving data or not.
I've had a read through the question/answer here which gives me a glimmer of hope, however the big difference between that question and mine is the endpoints of each request. For the API I'm using, they're all the same :(
Every single request must POST to /api/api_post.php, and everything else is specified as a parameter supplied in the request.
Obviously I can roll my own request wrapper to handle this, but I'd love to be able to use some of the functionality provided by Siesta and not have to worry about all the annoyances of dealing with networking. Is there any way of doing this at all, or am I out of luck?
You can make your app work with an imaginary REST API, then transform that to non-restful requests underneath Siesta’s nose. (For example, GET /foo/3 might be transformed to POST /api/api_post.php with item=foo&id=3.) It’s a bit of a hassle, but it does get you the benefits of Siesta even for non-REST APIs.
There are two ways to implement this:
Use mutateRequests(…) to rewrite requests. This lets you arbitrarily alter the URLRequest before it’s sent.
Write your own NetworkingProvider. This is a bit more of a hassle, but gives more wholesale control of the rewriting. This approach might be more suitable if, for example, you need to rewrite responses as well, or if you have to turn one virtual request into multiple real ones.
More in the discussion here.
I am trying to build a web based flash application. I am quite new to flash. I would like to develop it in two forms - demo and paid version. For this application to act as a paid version I need to have some kind of serial key. In order to achieve this I googled and came across something like this
MD5(MD5(thisuri)+thisuri)
I think 'thisuri' points to the current url page but I don't know how to get that url and I don't know whether '+' acts as a character or an operator.
Can you please help me?
It seems that a library exists in AS3.0 : as3corelib
An ActionScript 3 Library that contains a number of classes and utilities for working with ActionScript? 3. These include classes for MD5 and SHA 1 hashing, Image encoders, and JSON serialization as well as general String, Number and Date APIs.
To use it, just download the zip file, decompress it and copy the contents of "src" directory to the root of your project.
Then in your actionscript code, simply do the following :
import com.adobe.crypto.MD5;
var hash:String = MD5.hash(”test”);
source in french
To add to #Julien's recommendation of using as3corelib, you will also need the advice from this post to get the current url: Get Current Browser URL - ActionScript 3
Somehow I think there's a more elegant way to get the url, but I don't remember it.
While this may provide you with some basic check for the paid version, a determined hacker will easily fool this algorithm. For example, I could fool the environment into thinking that its being served from a domain that you've registered as part of the "paid" version. Also, since the client has the flash code, they can decompile the binary and potentially see the algorithm you're using. Depending on what you're offering in the app, this extreme case may or may not be acceptable to you.
Look into more secure authentication mechanisms if you're serious about security.
I'm trying to delete blobs in an mvc 3 application that uses azure storage.
I'm trying to pass the Uri of the blob which will be deleted to the controller, however an error is thrown:
A potentially dangerous Request.Path value was detected from the client (:)
I think this is from the https: part of the Uri and I need to parse it out, however I'm not sure how to do that. I'm wondering how to fix this error.
Is there a more graceful way to delete a blob from storage?
You must properly URL encode your urls. Here's an example of a badly encoded url:
http://foo.com/controller/action?param=http://bar.com
Here's how it should look like:
http://foo.com/controller/action?param=http%3A%2F%2Fbar.com
Or maybe you are having an url of the form:
http://foo.com/controller/action/https://bar.com
which is even worse. If you want to use special characters in the Path portion of an URL you might find the following blog post useful.
If you want unsecure content to get through then you can add [ValidateInput(false)] to your action - however, this is opening up something that is there for your security - so only do this if you are sure you're code is secure - see first answer in A potentially dangerous Request.Form value was detected from the client
I was able to fix it and I want to summarize the solution, since it requires bit from the other two answers and bits mostly from the Scott Hanselman Blog post.
You need to do a few things to make this work:
Put the [ValidateInput(false)] on your action method.
Make sure your Url is properly encoded (an example is given in the above post) which is done when you use the blobVariableName.Uri.AbsoluteUri as the string to pass from your view to your controller, so you shouldn't have to do anything there.
Make your query string looks like
http://site/controller/action?blobid=http%3A%2F%2F... and NOT http://site/controller/action/http%3A%2F%2F... the latter won't work!
On a side note, since I started, our functional requirements changed and now were storing information about each blob in the database, which allows me to pass parameters other than the blob's uri, which seems like a much safer way to play it.
A great deal of the community appears to be in agreement that it is a bad idea to pass uri's and to open up your application as to allow you to do so.
I feel dumb for not knowing this, but I see a lot of links in web pages and instead of this:
<a href="http://foo.com/">
...they use this:
<a href="http://foo.com/?src=bar.com">
Now I understand that the ?src= is telling something that this referral is coming from bar.com, but I don't understand why this needs to be called out explicitly. Can anyone shed some light on it for me? Is this something I need to include in my program generated links?
EDIT: Ok, sorry, I'm not being clear enough. I understand the GET syntax with a question mark and parameters separated by ampersands. I'm wondering what's this special src parameter? Why would one site link to another and tack an src parameter on the end even though there's no indication that the destination site uses this normally.
For example, on this page hover your mouse over the screenshot. The link URL is http://moms4mom.com/?src=stackexchangesites
But moms4mom.com is our site. Passing the src parameter does nothing, so why include it?
There are a few reasons that the src is being used explicitly. But in general, it is easier and more reliable to trust a query string to determine referer[sic] than it is to trust the referer, since the latter is often broken, deliberately or not. On the other hand, browsers almost never break the query string in a url, since this, unlike referers, is pretty important for pages to function. Besides, a referer is often done without any deliberate action on the part of the site doing the refering, which some users dislike.
The reason (I do it) is that popular analytics tools sometimes make it easier to filter on query strings than referrers.
There is no standard to the src parameter. Each site has its own and it's usually up to the site that gets the link to define how it wants to read it (as usually it's that site that's going to pay for the click).
The second is a dynamic link, it's a URL that another language(like ASP and PHP) interpret as something to do, like in those Google URLs, but i never used this site(foo.com), then i don't much things about this parameter.
Depending on how the site processes its URL, you may or may not need to include the ?... information.
This is passed to the website, and the server can process it just like form input. Some sites require this - and build their navigation off a single page, using nothing but the "extra" stuff passed afterwards. If you're generating a link to a site like that, it will be required.
In other cases, this is just used to pass extra, unrequired info (such as advertising, tracking info, etc)... In those cases, you can leave it off.
Unfortunately, there's no way to know without trying whether you can remove the "extra" bits from the URL.
After reading some of your comments - I'll also say:
There is nothing special about the "src" field in a query string. The server is free to use it any way it wishes. Unless you know specific info about the server, you cannot assume it can be left out.
The part after the ? is the query string. Different sites use it for different things, and it is usually used for passing information to the server side code for that URL, but can also be used in javascript.
For more info see Query String