Scenario: My general portal is hosted in IIS using ASP.NET and a login page. After successful login via WCF service, the session token is stored in the HTTPContext.Current.Session under mytoken.
The portal page hosts a Silverlight app in an iframe. The SL app opens a new tab using System.Windows.Browser.HtmlPage.Window.Navigate().
The tab is supposed to offer a file for download. The page called is an aspx page. It accesses HTTPContext.Current.Session["mytoken"] to get the current session token.
This works fine at all my customers except one.
Problem: At this one customer, the download tab gets null from HTTPContext.Current.Sessions["mytoken"]. I added a trace to confirm that. It does not work in either IE or Firefox.
The download page works fine when called on the web server directly. And each customer has a very similar setup and it works everywhere but at one site.
Does anybody know what to look for? How can the session be shared at all sites except one?
Thanks for any help!
We found the reason for our problem. It had something to do with using the IP address and/or the machine name in the URL.
It does not work if the portal uses http://machine1/portal/main.aspx and the new tab uses http://123.345.789.123/portal/download.aspx. Or the other way round. It seems that the session is not shared in that case, even though the IP address is the one belonging to the machine name.
I had the base URL for the download link hard-coded in the configuration of the SL app. So it did not build the download aspx's URL dynamically based on its own root URL.
I am now using Application.Current.Host.Source and its properties Source, Scheme and Port to construct the base URL on the fly in the Silverlight cllient.
Everything works like a charm now.
Related
I just created a webform that is hosted in my Azure subscription. I set it up with authenication via my works Azure directory for authenticating users. In debug this works fine and I am able to login with my work credentials and then view the website via local host.
I have published this to my Azure and it says it is running and working fine. So when I try to connect to the website it continuously redirects me to the localhost resulting in an error.
I have checked the web config.
Here is the google network chain of events when it occurs.
I am really lost as to what is wrong and what I need to do to fix this so any help would be greatly appreciated. I'm sorry I can't offer more but I don't even know what is wrong to begin with or where to look. Is there some setting in Azure that I need to add the website too?
I have solved this issue. Since it was such a pain I will keep this up as I couldn't find any answers on this. It was actually quite simple.
You have two options. The one I did and which worked was changing the publish profile as below:
Add the domain where the authentication is occurring. So if you have your web app hosted by a different azure account that which is authenticating the users, use the one that is authenticating.
This will create two versions of your app on the site one for local host and one for the actual site.
The second option(I have not tried this but it should work) is to go to the Azure account where you are authenticating the users and go to applications and then configure. Change the APP URL from local host to the url you are trying to get to.
Here is an excellent link that explains how to do this clearly.
Click this link for detailed explanation
I also had this issue and took these steps to resolve
navigate to the app registration in AAD
Open the manifest
Change the ReplyUrl to the url of the app (e.g. http://appname.azurewebsites.net)
Then I got the error
Bad Request - Request Too Long HTTP Error 400. The size of the request headers is too long.
Next I cleared all cookies from the browser, and this changed the error to just
Bad Request
So I went back to that ReplyUrl and changed it to https://appname.azurewebsites.net/.auth/login/aad/callback and now it appears to work.
Note I also had to make sure I didn't have the site open in any other tabs before it started working
I had this issue when I switched an app from our company Azure over to a customer's Azure. In my case I'd forgotten to update the ida:ClientId, ida:AADInstance and ida:TenantId, which then meant that the value I'd set for ida:PostLogoutRedirectUri was ignored (I think) and instead my app redirected to localhost.
Once I changed those ida values to the values from the app settings and subscriptions settings on our customer's Azure it all worked as expected.
It took a while to track down all the values in Azure portal as they are all called something different, or aren't named at all:
ClientId can be found at Azure Active Directory > App Registrations > YourAppName. It's called 'Application ID' in Azure
Domain can be found on Azure Active Directory > Overview. It's currently in the top left in the format somename.onmicrosoft.com
TenantId this is the Azure AD instance ID, get that from Azure Active Directory > Properties and then it's called 'Directory ID'
I spent a lot of time trying to work out where the localhost port that was being redirected to was in the code, but it simply isn't there as far as I can see, so I have no idea how Azure was choosing what localhost address to redirect to!
You need to set another parameter in configuration that is replyUrl and assign to your web app, other wise it takes the url from which it was originated.
I was able to fix this by changing my Startup.Auth.cs file redirectUri from "https://localhost:44316/" to https://myapp.com/
Can I have a ribbon button launch an aspx ( asp.net ) page? The aspx page needs to inherit authentication and authorization as the logged in Dynamics user.
You can execute custom JavaScript from a ribbon button allowing you to spin up a new browser window pointing at whatever you like.
To inherit security credentials you need to look at setting up federated authentication across both the CRM server and the custom website hosting the ASPX. As you can probably imagine this isn't a trivial task.
You could also look at dropping your website into the custom ISV folder as was the case with CRM 4. However, this approach has been deprecated in CRM 2011 and AFAIK is therefore no longer supported.
As #Konrad pointed out you won't be able to use the Data Service REST API (OData) from your custom web pages as the service is only accessible from web resources hosted within the CRM environment. Server-side you'll be fine against the Org Service.
If you can get away with doing what you need in a web resource I'd highly recommend it as it's a whole lot less work.
I'm not sure you can do that. A while ago, I put in an iframe that I linked to an outside web page and it worked as supposed to except for connecting to the organization data. I just couldn't make that work (I got impatient, to be honest and didn't try all too hard).
The resolution I deployed in the end was to run a web resource, which was run internally on the server, that communicated the data to an outside service.
I'm assuming that the same behavior will follow if you try to open windows/convey data in to/out from the CRM.
I want to provide a means to open up Windows Explorer (or at least view the directory contents) via an internal webpage I've developed for our business. There are several machines which we share over the internal network. I've provided a text entry field for allow the user to enter the folder path they want to associate with a given row in a DB table and I can store that info off and create the file://///10.10.5.10/Recipes/Pie link to the Pie recipe folder on one of our shared machines.
The link renders correctly on the page and if I copy the link info and paste it into the address bar it will display a navigable page in FireFox or open Windows Explorer if using IE.
However, the link does nothing if you click on it directly on my page. I suspect this might have something to do with security and the brower, right? I've seen a SharePoint page in someone else's system that did work, but I'd guess that has to do with some differences between SharePoint and a webpage in a browser. The work-around of right-clicking the link and copy/pasting it into another tab will work and I might have to live with this, but I was wondering if anyone had any suggestions or ways to deal with this issue. Perhaps I'm just doing something wrong, but I'm pretty sure it's browser-security related.
It seems for me as a pure Internet Explorer setting issue.
First of all I would recommend you better use UNC or DNS names in the path to the server instead of the usage of IP addresses: use file://///myserver/Recipes/Pie or file://///myserver.mydomain.com/Recipes/Pie instead of file://///10.10.5.10/Recipes/Pie.
Second you should better include the file://///myserver, file://///myserver.mydomain.com or even file://///10.10.5.10/ to the "Local intranet" or at least to "Trusted sites" zone:
Then you should verify the setting of the Security Zone to which you map the url. Look at the "Miscellaneous" group for the "Display mixed contain":
If you would has "Prompt" setting you will see the warning:
at every attempt to open the link file://///myserver/Recipes/Pie
If you would has some problems I recommend you to reset the IE settings in "Advanced" tab:
Most likely it's a permission issue.
ASP.net runs under the ASP.net process account. Look for the ASPNET user and apply permissions to the folder for the user in question.
It definitely sounds like a security issue. Try one or both of the following:
Try using impersonation to impersonate a domain user with sufficient priveleges to access explorer on the client's machine
If this is a small intranet application, give the application full trust on the client
Here's a link to a class you can use for impersonation - see my answer:
Invoke or call C# console app from C# web service?
I have an aspx page and I want to access an application on the client after seeking user permission. Both the windows application and the website are to be made in VB.NET. Does any one have any idea as how to go about solving this problem?
Thanks
EDIT:
Here is the problem. From my .aspx webpage in vb.net, a visitor clicks on a link on my site, and if my winform is not already loaded on their desktop, it is then loaded with the users permission. This application should auto-load on the user's site at boot up time and always be in the background running. Make it an extremely thin client, taking the least cpu and bandwidth from the user, and running as a silent background process until needed.
Whenever the user visits one of my many websites, IN ANY BROWSER, somehow - the app running in the background communicates with the .aspx on one of my sites, and exchanges a silent username password identifying client winform app to the online .aspx app on my website.
Then the .aspx on my site PASSES a url such as "www.somewebsite.com" to the app running in the background, the background app then does a http request from the client's computer, not from my .aspx server, so the client's cookies and ip are visible to "www.somewebsite.com" server. The client collects the html for that page, stores it as a string, and also saves the ascii of that webpage as another string.
Both strings then are PASSED BACK to my .aspx website that the client is visiting, and the .aspx app then stores these results in a database.
I don't see anyway your web page can access/execute an executable from a client's hard drive. May be with RIA components (Silverlight, Flash, etc), but not sure. You could however register a protocol like myapp: on client when installing your windows app to that machine and invoke a url from the web using that protocol with appropriate data passed as arguments. Then it's up to the windows app to communicate to the server and get the things done. Here is an MSDN article to get you started.
The only somewhat similar thing I've done like this is launching and manipulating Outlook from within a webpage, by generating the necessary VbScript. This of course implies that your users will only use IE to access your website.
Set olApp = GetObject(, "Outlook.Application")
Set objFolder = olNs.GetDefaultFolder(oCalendarDefault)
Set MyItems = objFolder.Items
etc
I am creating a standalone asp.net page that needs to be embedded into a sharepoint site using the Page Viewer Web Part. The asp.net page is published to the same server on a different port, giving me the URL to embed.
The requirement is that after a user is authenticated using Sharepoint authentication, they navigate to a page containing the asp.net web part for more options.
What I need to do from this asp.net page is query Sharepoint for the currently authenticated username, then display this on the page from the asp.net code.
This all works fine when I debug the application from VS, but when published and displayed though Sharepoint, I always get NULL as the user.
Any suggestions on the best way to get this to work would be much appreciated.
If you want to retrieve the currently authenticated user from the SharePoint context, you need to remain within the SharePoint context. This means hosting your custom web application within SharePoint (see http://msdn.microsoft.com/en-us/library/cc297200.aspx). Then from your custom application reference Microsoft.SharePoint and use the SPContext object to retrieve the user name. For example:
SPContext.Current.Web.CurrentUser.LoginName
You can still use the Page Viewer Web Part to reference the URL of the site, now located within the SharePoint context.
Thanks heaps for the answers!
Turns out that as long as the asp.net page is using the same URL and port as the Sharepoint site, authentication works across both sites.
The solution is to use a Virtual Directory inside of the sharepoint site and install the asp.net page there.
When it works in debug, is that being used in SharePoint?
Your page and the Sharepoint site might as well be on different servers as far as authentication is concerned -- in order to get the information over you might need to pass it via the QueryString from the webpart if you can -- or you might need to make your own webpart to do this (just put an IFRAME in the part with the src set to your page with the QueryString passing the username).
It does seem that this would be a security issue if you use the name for anything though -- if you are just displaying it, then it's probably fine.
If you actually need to be authenticated, you might need to add authentication into the web.config of the site hosting your standalone page.
edit: I think you'd have better luck putting your page on the same port and server as SharePoint.
I suspect you will have a hard time specifically querying SharePoint for the currently authenticated username. I can't think of a way to easily access the SharePoint context from a separate web application like you are describing.
I don't know what kind of authentication scheme you are using, but you may want to consider using Kerberos, as I've found that it can make these kinds of scenarios a little easier by allowing for delegation and passing credentials from application to application or server to server.