is it possible to assign a value to a ServerVariable("Something") using the code? instead of doing it via the IIS?
something as simple as this?
Request.ServerVariables("LOGON_USER")="test"
i also found the following at another forum:
Request.ServerVaria bles.Add(name, value)
but i keep getting the same error on both:
"Declaration Expected"
some background:
i am trying to do is pass in the ("LOGON_USER") variable from one applicaton to another (on a different domain), to somehow allow for single sign on. I now pass hidden variables to the new server and then want to assign them to proper servervariables.
would I then need to edit response or request? am i waaay off on this?
Single sign-on is not usually implemented in this manner. Typically you would authenticate the user in the first system, create a secure token, then pass the token along with some identifying information to the second system. The second system would validate the token and the additional data, and if successful, authenticate the user in the second system (usually by creating an auth cookie).
This link gives you an overview of one approach, but you can Google for other techniques:
http://msdn.microsoft.com/en-us/library/ms972971.aspx
You can set server variables (although you would usually want to change the response rather than the request), and the most likely place to do this would be in a custom HttpModule. You can find more info here:
http://learn.iis.net/page.aspx/686/setting-http-request-headers-and-iis-server-variables/
and
http://forums.asp.net/t/1125149.aspx
Related
Let's say I want to create environment's domain for users with different roles: Regular role and Admin role. I need user's auth token for every request, so I set header value for /auth/signin/ as a dynamic value:
Respone Parsed Body/auth/signin/ > token
But when I switch user environment from one role to another, dynamic value for token doesn't count new environment. And every role uses the same token for authentication.
What is the best way to work with different roles?
That's a good question. Currently "Response Parsed Body" dynamic values are using the latest response, regardless of the current selected environment. (We're going to make it possible in a future release)
What I suggest for now (as a workaround) is to create two different auth/login requests, one per environment/role, and a new environment variable that would point to the right request. I tried to explain this through this screencast: http://cl.ly/1X0B2H2o1o1S
I'm not currently able to use all of Meteor's accounts functionality for compatibility reasons. My system is quite simple, though, I expose an "authenticate" method on the server that performs the necessary authentication work and then, if successful, sets the value of Meteor.userId() via this.setUserId. The only problem is that when I call this.setUserId on the server, it doesn't seem to propagate back to the client. Meter.userId() continues to return null on the client, but returns the correct value on the server. Since this.setUserId is a server-only function, I'm at a loss as to how I can set the correct user ID on the client after the "authenticate" method returns. Ideas?
You need to do more than just set the userId in order to authenticate a user. Check out these examples for how to do custom authentication:
https://github.com/tmeasday/meteor-accounts-anonymous (creates a user for each browser session)
https://github.com/mizzao/meteor-accounts-testing (creates users without passwords)
The second one is my example. I would strongly suggest building off the functionality provided by the base accounts package instead of rolling all your own operations.
EDIT: Based on the OP's response, one might be interested in doing a different kind of operation that is not about authenticating; see the following:
https://dweldon.silvrback.com/impersonating-a-user
Despite the fact that the Meteor documentation lists "this.setUserId()" as Server-only, it does currently work on the client too, so that's how I ended up solving this issue.
I need to share session in order to pass data from asp page to aspx. The solutions I've found:
• Pass data through hidden form (link)
• Pass data through database (link)
I've tried method with form and it worked fine (after some modification). Now I'm trying method with database. First method is easier imho, so I wonder if the second method is more secure (and preferable) than the first one?
And what potential problems exist with these methods?
The first solution is definitely less secure since you're sending session data to the client and then receiving it back. That means that it's possible for someone on the client side to modify the data they post back to your page. This removes one of the best things about sessions, that only the programmer controls what's in them. In a way, the first method is similar to using cookies. As for the second method, it may be more difficult but I would definitely recommend it over the first.
If the session is encrypted I think you will fine. ASP.NET has the option of storing the session in a database and URL querystring to get around users not having cookies enabled. Your solutions sound similiar.
Microsoft outlines a method to share session state between ASP classic and ASP.NET using SQL Server to store the session here: http://msdn.microsoft.com/en-us/library/aa479313.aspx
Is there a "clever" way of stopping direct page calls in ASP.NET? (Page functionality, not the page itself)
By clever, I mean not having to add in hashes between pages to stop AJAX pages being called directly. In a nutshell, this is stopping users from accessing the Ajax pages without it coming from one of your websites pages in a legitimate way. I understand that nothing is impossible to break, I am simply interested in seeing what other interesting methods there are.
If not, is there any way that one could do it without using sessions/cookies?
Have a look at this question: Differentiating Between an AJAX Call / Browser Request
The best answer from the above question is to check for a requested-by or custom header.
Ultimately, your web server is receiving requests (including headers) of what the client sends you - all data that can be spoofed. If a user is determined, then any request can look like an AJAX request.
I can't think of an elegant method to prevent this (there are inelegant and probably non-perfect methods whereby you provide a hash of some sort of request counter between ajax and non-ajax requests).
Can I ask why your application is so sensitive to "ajax" pages being called directly? Could you design around this?
You can check the Request headers to see if the call is initiated by AJAX Usually, you should find that x-requested-with has the value XMLHttpRequest. Or in the case of ASP.NET AJAX, check to see if ScriptMAnager.IsInAsyncPostBack == true. However, I'm not sure about preventing the request in the first place.
Have you looked into header authentication? If you only want your app to be able to make ajax calls to certain pages, you can require authentication for those pages...not sure if that helps you or not?
Basic Access Authentication
or the more secure
Digest Access Authentication
Another option would be to append some sort of identifier to your URL query string in your application before requesting the page, and have some sort of authentication method on the server side.
I don't think there is a way to do it without using a session. Even if you use an Http header, it is trivial for someone to create a request with the exact same headers.
Using session with ASP.NET Ajax requests is easy. You may run into some problems, like session expiration, but you should be able to find a solution.
With sessions you will be able to guarantee that only logged-in users can access the Ajax services. When servicing an Ajax request simply test that there is a valid session associated with it. Of course a logged-in user will be able to access the service directly. There is nothing you can do to avoid this.
If you are concerned that a logged-in user may try to contact the service directly in order to steal data, you can add a time limit to the service. For example do not allow the users to access the service more often than one minute at a time (or whatever rate else is needed for the application to work properly).
See what Google and Amazon are doing for their web services. They allow you to contact them directly (even providing APIs to do this), but they impose limits on how many requests you can make.
I do this in PHP by declaring a variable in a file that's included everywhere, and then check if that variable is set in the ajax call file.
This way, you can't directly call the file ever because that variable will never have been defined.
This is the "non-trivial" way, hence it's not too elegant.
The only real idea I can think of is to keep track of every link. (as in everything does a postback and then a response.redirect). In this way you could keep a static List<> or something of IP addresses(and possible browser ID and such) that say which pages are allowed to be accessed at the moment from that visitor.. along with a time out for them and such to keep them from going straight to a page 3 days from now.
I recommend rethinking your design to be sure that this is really needed though. And also note IPs and such can be spoofed.
Also if you follow this route be sure to read up about when static variables get disposed and such. You wouldn't want one of those annoying "your session has expired" messages when they have been using the site for 10 minutes.
Do Pagemethods and Json have security risks?(I dont use cookies).Forexample i have a pagemethod and i am sending user id as a parameter but i dont want to show it to user.Can user get user id from pagemethod?
yes they can (see the user id). Any communication between the server and client can be seen by the user. Take a look with fiddler or firebug to see what goes on. You can treat it the same as any regular get or post request.
I know of no reason why not to use it. Without knowing any of the background I can't give a definitive answer on whether I would choose it but in general there is no reason not to use it just apply the same security you would use for HTTP get and post requests like in regular form submissions.
It has the same security risks as a regulat GET and POST, it is just another format to send the data back and forth. If you were using a regular POST, anyone would be able to see the userid just the same.
So if you don't want to have people messing up with the userid you could add some sort of encrypted string dependent on the userid to go along with it, for validation, to name one of many possible solutions.
JSON has no security by itself, It's an unencrypted data-format.
JSON can utilize FormsAuthentication security just like pages. What I usually do if I don't want the end-user to see an identifier, is to store that value (or something I can use to lookup that value) in User.Identity.Name.
The most complicated part of this approach is that the JSON may not return anything if you aren't authenticated. To work around this, I tend to include a non-authenticated page for getting JSON to tell you if the user is logged in or not.
I am hiding user id parameter in Hidden Field and just concerned that can it be changed while in that Process.Thanks all of your supports
if the userid is in a hidden form field, then it is completely exposed to anyone who views the source code in the browser. Not only can they see the userId, but they can see how you are sending it to the server.
In general, you never trust the client with sensitive data. Assume that they can always manipulate the response.
The way to securely pass messages is to give the user some session token in the form of a string. This session token should be generated with a fair amount of randomness and includes their username in the algorithm. Take a look at resources regarding md5 and salting. With this token that you give them, the assumption is now that they cannot reverse engineer the contents. Since they do not have the algorithm (it is sitting on the server side), then they cannot tamper with it. Your server will have to decrypt the session token to retrieve the userId of course.
This in itself does not mean your application is completely secure - it only fixes one of potentially many issues.