I have developed one application and facing issue with security stuff.
My application is running in doPost method which doesn't explicit the URL in browser. If I'm trying to change the doPost to doGet (using webdeveloper tools-->Forms), my application's URL will be displaying explicitly. So I need to throw an error/stop app response, If user tries to change the forms from doPost to doGet ?
I suppose the question here is: Why do you regard it as a security issue, that the URL might be displayed in the browser?
In case you don't want the user to have access to the URL or other request data, you probably have fundamental design problem, as the user can track the post request using the developer tools.
In case you don't want somebody else than the user to see the URL and thus think it should not be displayed in the browser, I would not worry, as the user has to actively and consciously "mess" with your application to achieve this behavior.
In general it is probably a good idea to throw errors and prevent the request from being processed if your front end does not behave as expected.
Related
I want to 301 redirect the URLs from previous site that are nested, as pencilblue doesn’t support them,
e.g. a/b to page/b
For this I have been experimenting in include/http/request_handler.js but facing some issues.
Call never comes inside RequestHandler.prototype.handleRequest or even RequestHandler.prototype.onSessionRetrieved (seems these methods are not being called from anywhere)
Therefore I placed the code in RequestHandler and after confirming that req is not for public resource or api, I create a new url and execute
return this.doRedirect(newUrl, 301)
This actually works but at the same time I receive
Can’t render headers after they are sent error
#1075 has not helped me much as I’m not sure which specific controller I should modify. I need to catch the req as early as possible and see if it’s a page then redirect to page prefixed url.
Thanks in advance.
There are couple of ways to do redirects. You can do them from a controller or from middleware. You are correct in that, some of the functions in the request handler are not called. These are deprecated despite the fact pencilblue team didn't mark them as such. They replaced a good deal of the request handler functionality with /include/http/router.js and include/http/middleware/index.js. Plugins can register their own middleware to hijack the request pipeline.
See Advanced Routing on wiki for more info about creating your own middleware.
Using the routing framework your plugin would be able to register middleware that would be able to inspect the request and then redirect based on your specific criteria. The Router will be accessible from req.router and from there you could call req.router.redirect (Source).
Reference: #1224
We are using form-based auth in our GWT application and I'm currently struggling a lot with session timeout.
If the user is logged in and performs an action that will trigger a request for a static resource AFTER the session has timed out, then the login page is shown and when the user logs in again, then only the image resource is shown to the user. An example is if the user hovers the mouse over a button, and the button need to fetch a icon which is shown on mouse over.
It is logical that this will happen, since the login page was triggered by the request for the image, but it is not really the behavior that we want. It would much better that the user is redirected to the page he was on, or alternatively another page.
How can this be handled in a better way? As I understand it is very difficult to change the redirect url, which j_security_check uses to redirect the user after successful login.
The way I solve it is to only protect the HTML host page with a <security-constraint>. Static resources (images, stylesheets, GWT scripts) aren't protected at all, and AJAX endpoints (GWT-RPC, RequestFactoryServlet, or other endpoints called using AJAX from the app) only check the presence of a user Principal in the request (this can be done in a servlet filter, or a RequestFactory ServiceLayerDecorator), and return an error otherwise (but do not trigger the login page).
You can see an example web.xml here with the code to handle the security in RequestFactory here (and the code to handle the response on the client-side here). For GWT-RPC, you'd probably do that using a servlet filter and a custom RpcRequestBuilder or a base AsyncCallback<?> implementation.
I have created a class that generates a URL that authorized my users with Facebook. Here it is:
https://www.facebook.com/dialog/oauth?response_type=code&client_id=...&scope=email%2Cuser_about_me%2Cuser_friends%2Cuser_hometown%2Cuser_location%2Cuser_work_history%2Cuser_education_history%2Cpublish_actions&state=...&redirect_uri=http%3a%2f%2flocalhost%3a53016%2fsocial%2fcallback%3fvariables%3dY2FsbGJhY2tfdXJsOi9MYW5kaW5nO2ZhbGxiYWNrX3VybDovQ29uc3VsdGFudC9TaWduVXA7bWV0aG9kOjE7cHJvdmlkZXI6MQ%3d%3d
This URL works just fine and returns back to my callback function. I'm able to convert the base64 string to my variables that I pass along with my URL. The trouble that I am facing is that Facebook doesn't recognize the URL to give me the access_token. This the return URL that I send to Facebook for the access_token.
https://graph.facebook.com/oauth/access_token?client_id=...&client_secret=...&code=...&redirect_uri=http%3a%2f%2flocalhost%3a53016%2fsocial%2fcallback%3fvariables%3dY2FsbGJhY2tfdXJsOi9MYW5kaW5nO2ZhbGxiYWNrX3VybDovQ29uc3VsdGFudC9TaWduVXA7bWV0aG9kOjE7cHJvdmlkZXI6MQ%3d%3d
(I have cleared out the client_id and client_secret for obvious reasons.)
Can anyone notice what I am doing wrong here?
Perry thank you for your help. I was able to figure out what the problem was on my project. When I was encoding my parameters to Base64 I wasn't using the proper methods to convert it to String. This answer on stackoverflow helped me figure out what I was doing wrong.
C# Method like Base64String, but only alphanumeric (no plus or slash)
The answer in particular is from Mason G. Zhwiti. I was just doing Convert.Base64String instead of HttpServerUtility.UrlTokenEncode(byte[] b). After I did that I was able to get my response. I seemed that my URL had two equal symbols at the end. That was throwing off Facebooks URL validation. Once I did the appropriate method it started working.
I hope this helps anyone else who is struggling with this type of problem.
What is the specific error message - was it unauthorized redirect_uri?
I'm kind of oblivious to the variables - what are they for?
It doesn't seem like you should be doing the callback to a querystring URL, but maybe that's OK. When I first implemented OAuth2, I had the API calls originate from and callback to specific URLs for each provider, such as mysite.com/login-google.php or mysite.com/login-facebook.php, but now I have the callbacks point to the main site URL (mysite.com). Since we have index.php at the main site URL, we can intercept the callback in index.php and route them to the desired provider script (login-google.php or login-facebook.php) which cleans up the callback URLs and makes them a no-brainer for end-users to work with.
Your callback URL:
http://localhost:53016/social/callback?variables=Y2FsbGJhY2tfdXJsOi9MYW5kaW5nO2ZhbGxiYWNrX3VybDovQ29uc3VsdGFudC9TaWduVXA7bWV0aG9kOjE7cHJvdmlkZXI6MQ==
Can you access that callback URL in a browser? Code it up to throw an error or output a debug message so you know the callback URL is working.
I've documented the OAuth2 flow for Facebook quite cleanly in this code: https://github.com/perrybutler/WP-OAuth/blob/master/login-facebook.php
Hope it all helps...
Is there a way to go to a url without redirecting to it? Basically I want to call a url from within my application in the background so it can logout a reliant party.
Appreciate the help.
What you are trying to do does not compete us to answer as it's directly related to your own Authentication implementation.
A normal ASP.NET Authentication based in Forms Authentication you will need always to lunch the url from a browser as it is there that relies the Authentication given.
You can give yourself a try by opening your website and log in into it, after that, open other browser brand (not browser window) into your application url... you will see that you also need to login again as the Authentication is hook up into the first browser.
It's Up to you as Application Architect to make this by implementing another way of authentication, normally in this kind'a cases, this happend when consuming web services where you need a authentication code first (given by calling a Login method) and that code is always needed to be appended to the body or header of any call to the system.
This way you can easily remove the authentication code and all procedure calls will fail.
As said, this is not up to us, it's up to you to create the correct Authentication Layer.
from your comment
it's as simple as using WebClient object
WebClient client = new WebClient ();
string reply = client.DownloadString (address);
If you wish to transfer to a new url request you can still use
Server.TransferRequest()
The problem with this is that by not using a redirect the browsers address bar will not reflect the fact that you have moved their request to another URL.
To have the client visit a given URL in the background you should either make an AJAX call to it or possibly have an image with an src of your logout url (though you'd have to make sure that you return a FileResult of your image too). This is how most analytics packages call to their relevant urls in the background.
The problem here though is that neither is 100% reliable, turn off javascript or images on your browser and these results fail.
From what you've said I think what you're after is for a user to continue to any of a variety of pages rather than a specific logout page. If this is indeed the case your best solution is in fact a double redirect.
Have your application redirect to your logout url but before hand put the url of the page you want them to go to into tempdata. Then in the actionresult for the logout page you can do your logging out as required and return a redirect to the url from tempdata.
Why does using Fiddler break my site sometimes on page transitions.
After a server side redirect -- in the http response (as found in Fiddler) I get this:
Object moved
Object moved to here.
The site is an ASP.NET 1.1 / VB.NET 1.1 [sic] site.
Why doesnt Fiddler just go there for me? i dont get it.
I'm fine with this issue when developing but I'm worried that other proxy servers might cause this issue for 'real customers'. Im not even clear exactly what is going on.
That's actually what Response.Redirect does. It sends a 302 - Object moved response to the user-agent. The user-agent then automatically goes to the URL specified in the 302 response. If you need a real server-side redirect without round-tripping to the client, try Server.Transfer.
If you merely constructed the request using the request builder, you're not going to see Fiddler automatically follow the returned redirect.
In contrast, if you are using IE or another browser, it will generally check the redirect header and follow it.
For IE specifically, I believe there's a timing corner case where the browser will fail to follow the redirect in obscure situations. You can often fix this by clicking Tools / Fiddler Options, and enabling both the "Server" and "Client" socket reuse settings.
Thanks user15310, it works with Server.Transfer
Server.Transfer("newpage.aspx", true);
Firstly, transferring to another page using Server.Transfer conserves server resources. Instead of telling the browser to redirect, it simply changes the "focus" on the Web server and transfers the request. This means you don't get quite as many HTTP requests coming through, which therefore eases the pressure on your Web server and makes your applications run faster.
But watch out: because the "transfer" process can work on only those sites running on the server, you can't use Server.Transfer to send the user to an external site. Only Response.Redirect can do that.
Secondly, Server.Transfer maintains the original URL in the browser. This can really help streamline data entry techniques, although it may make for confusion when debugging.
That's not all: The Server.Transfer method also has a second parameter—"preserveForm". If you set this to True, using a statement such as Server.Transfer("WebForm2.aspx", True), the existing query string and any form variables will still be available to the page you are transferring to.
Read more here:
http://www.developer.com/net/asp/article.php/3299641/ServerTransfer-Vs-ResponseRedirect.htm