-- background --
I have a customer intranet (ASP.NET / VB) thats instantiating an asp.net session checking various things in the dblogin process. The Intranet has various sub-systems.
The marketing sub-system requires an app_role to be assigned to the Intranet user for them to view the section.
I need to create a new booking form for this section but the code appears to use a generic form which is use throughout the site in various other sections. So its not a good idea to ammend what is currently there.
-- My plan --
Create a new application in C# / ASP.NET and also in IIS. (rather than a new site, create an app within the Intranet site in IIS)
Will I be able to check for the session thats currenting set in the cookie?
If the session is open then the user is able to see the Intranet and I assume I will need to do some checks for the app_role too.
I am simply going to put the URL for the app in the menu for marketing and then do another check just incase someone gives the URL to someone who doesnt have access to the menu.
--My Question--
Will i be able to check and use the cookie thats been instantiated by another application?
No - Sessions (session cookies) are application specific. You can try sharing sessions between applications via SQL and see if that works. As for membership/roles, see this.
Still, unsure why building a separate (web) app (which introduces the issue) is the way to go. If your plan is to introduce another form then why can't this be done in the existing intranet app?
Related
I have a specific web page developed using Web forms c# that should be accessed through only an internal DNS.
the whole site can use both external and internal except for this page.
So, my question is how can I check wither the user is using internal vs external DNS in the backend c# code ?
Thank you for your help.
If you want to do it on the applicaiton level, you will need some form of authentication. Basically you can implement any kind of authentication, but to start I would recommend to look up IPrincipal. Here's a starting point: https://learn.microsoft.com/en-us/aspnet/web-forms/overview/older-versions-security/introduction/an-overview-of-forms-authentication-cs
If you want to do it on the network level you might deploy this one page as a separate application, then do the checking on the IIS level.
I am building a UWP app for windows 10. I want the users to be able to login to a website and retrieve data from that site using the login information provided. How to login to a website programmatically and save the login credentials and login automatically the next time the user opens the app ? I want the login information to be available throughout the app so that in all the pag
It heavily depends on the web app you're trying to connect to. Actually, you don't connect to the web app or to a site but most likely to some backend services which back up the whole web application. The UI is called in this case a web client. What you are trying to do, is to create a desktop client (the UWP app).
Unless this site you're speaking of, has no clear documentation of how to use a certain API to connect to it, I don't see a way you can achieve this.
Additionaly, I am sure this whole approach will raise suspicions when your app might be eventually under certification, before being published in the Windows Store. If it doesn't pass the certification, only you can use it, others can't, 'cause it won't be available for them.
if you have the login information. I guess you have a token to make a valid requests.
Just need to save this information in the storage of your application and get the saved data when it will be necessary.
Please check this example how to use Storage in UWP apps
https://msdn.microsoft.com/en-us/library/windows/apps/mt185401.aspx
I recommend you to use Json format to save the data in your storage with this technique you can serialize a your data very easy.
here is an example:
http://www.codeproject.com/Tips/79435/Deserialize-JSON-with-C
I always use this approach in my apps and they work very well.
Best Regards
I have done a project similar to your project. My project involved logging in onto a website inside an UWP-application. I wanted to inject login-information into the DOM without the user knowing the information.
Quickly I concluded that the WebView Class is too limited and tightly protected to get it working. I resorted to an alternative webbrowser for UWP-applications named Gecko. Gecko is a .NET implementation of Firefox, found a tutorial on how to get it working and it worked right out of the box.
In the case of your project you have three options:
Use a UWP popup (MenuFlyOut class) where the user inserts their data. You then inject the inserted data into the DOM of the browser.
Let the user insert their credentials inside the DOM and intercept the keystrokes.
Let the user insert their credentials inside the DOM and retrieve the information by requesting the value of the inputs inside the DOM.
To use the values everywhere throughout the application you can create a static attribute inside the App-class inside the App.Xaml.cs file.
sealed partial class App : Application
{
internal static String Username { get; set; }
internal static String Password { get; set; }
public App()
{
If you want to use the variables again you can use them like this:
App.Username
I have web application which was developed in .NET 3.5, hosted on Windows server.
Outside people are accessing my web application by creating HttpWebRequest POSTs and passing the browser information along with necessary input values.
How to restrict access to my web application through HttpWebRequest?
You can't really restricted users from calling your site using HttpWebRequest (or 'not a browser', so to say) since all that information about the client machine, like the browser used, can be spoofed.
You have to wonder if you really want to go through all this. Do you want to make your users life miserable (or a least the user experience of your site)? If you do, you might want to use Captchas to make sure there is a real user and not a robot.
Do you keep the developer's control panel and the application's web service, in 1 project? or do you separate them into 2 different projects?
(Developer's control panel, is used to setup the web service API, check logs, read document specification, and details about each web service)
When you host the solution you would do something like this..
developer.domain.com <-- developer's control panel
api.domain.com <--- web service api
or
api.domain.com <-- both developer's control pnel and web service api
I would strongly recommend separating the two domains (e.g. into "developers.domain.com" for the control panel / documentation and "api.domain.com" for the API itself). This is important for cross-site-scripting safety.
If both are on "api.domain.com", the following can happen:
Suppose you are logged into the control panel, and thus have a cookie to api.domain.com
You now visit a completely different site, evildomain.com, which has some malicious Flash or Silverlight content that appears to do something innocent (e.g. a game, movie, etc)
The malicious Flash or Silverlight content tries to make a call to api.domain.com to steal or modify your personal information (it makes the call to a control panel page, NOT to the API itself!)
The malicious call would automatically get the login cookie attached to it by the browser, and so will look like a legitimate call to the control panel site
The api.domain.com will have to be cross-domain-enabled (with the crossdomain.xml file) to enable legitimate API calls from Flash/Silverlight clients, and so the malicious call will go through as well, and thus the control panel site will be compromised!
There are ways to avoid the attack above while still keeping the API and the control panel on the same domain, but the easiest way to avoid it is to separate the domains.
I don't see a reason to separate this when:
There is no technical reason to keep them separate;
You have authentication setup correctly so that you're sure only the developers can access this;
The developer tools are actually tied specifically to api.domain.com.
If you e.g. had multiple applications (api1, api2, api3, etc) and the developer site actually spans these different applications, then, yes keep them separate.
If the above reasons don't apply, go what you feel fits best.
Is there a proper .NET solution for providing persistent server sessions over multiple domains?
i.e. If a user of the site logs in under www.site1.com, they will also then be logged in under www.site2.com
Security is an issue with the program we are working on...
Thanks!
Does it need to be in the session or are you looking for a single signon solution. If the latter take a look at something along the lines of ADFS
http://en.m.wikipedia.org/wiki/Active_Directory_Federation_Services?wasRedirected=true
You may want to start here instead of hacking into the ASPState database(possible, but I don't recommend it): http://www.codeproject.com/KB/session/sharedsession.aspx
Basically you set the AppDomain to be the same for both www.site1.com & www.site2.com using reflection.
You also may need to AppPath as well, we needed to, but our setup was slightly different than what you have. We added:
FieldInfo appDomainInfo = typeof(HttpRuntime).GetField("_appDomainId", BindingFlags.Instance | BindingFlags.NonPublic);
appDomainInfo.SetValue(theRuntime, "/LM/W3SVC/1/ROOT/A_Website_Name_Here");
The word 'session' can be a little confusing in ASP.NET.
If you are talking about security (authentication and authorization), you are probably looking for a Single Sign-On solution. In other words, when a user logs into one site they won't be prompted to log into another related site. Take a look at Windows Identity Foundation, OAuth, Jasig CAS. CAS is my preferred solution (I'm a developer on the .NET client), but the server is written in Java and you'll need some expertise with Java to get it configured the way you want.
In ASP.NET, Session state is a completely separate component from authentication and authorization (although it can depend on the result of the authentication step). If you are trying to share information between the 2 sites (i.e., shopping cart contents), you can either configure both domains to use the same database as a Session provider (google aspnet_regsql -ssadd) or you can just store the data in a database that is accessible by both.
For more info on why I emphasize the distinction, check this out: http://www.codeproject.com/KB/aspnet/ASPDOTNETPageLifecycle.aspx
Good luck.
Try using the canonical hostname URL Rewrite feature of the IIS 7.5 Url Rewrite 2 Module: Download
(This answer relies on both URL have hostheader entries for the same web application)