I have a web application that is installed on 28 different servers that are very difficult to access. These apps are all mapped to a single base URL that I manage.
Is there a way to track views of a specific page in the app without installing tracking code on all 28 servers?
Related
As per my understanding, when user visits a url of a SPA application, the whole application is downloaded including any static html,assets and javascript. Can someone please clarify what role does the host web server play from there on? If after download of all the assets, I turn off the web server the application does not work. But ideally, it should work because now all the code to create any views is with the client already in form of javascript files. Let's assume there are no API calls for data.
Yeah it will work
If the application is fully loaded in browser it will work even after you turned off or disconnect the web server
Web Server No Need after the client has downloaded all the assets
I have asp.net hosted at my domain which i access using a url like 'http://www.xyz.com. I have other web applications which are under the root web application in virtual directories which can be accessed using a url like 'http://www.xyz.com/subsite1 etc.
Now i want to have a sharepoint site as a subsite under my root website which i can access using a url like 'http://www.xyz.com/sharepointsite1.
I have installed sharepoint 2010 server.This installed a new website Sharepoint-80 and The central administration site. I have changed the Sharepoint-80 website setting to point to wwwwroot where my asp.net wesite and its subsite files are located. Now if i make a new site collection in my sharepoint site and it gets successfuly created. But when i browse it i get following error.
HTTP Error 500.19 - Internal Server Error The requested page cannot be accessed because the related configuration data for the page is invalid.
My webserver is also a domain controller. How do i resolve this issue? And how do i achieve the main aim of having a sharepoint site as a subsite under my main website?
Thanx
I don't think that is possible, unless you are using different host headers or you can write an HttpModule which would be complex in my opinion. Although reverse is possible, You can have a sharepoint site at / and then an ASP.NET site at /subsite
The reason is an IIS SharePoint website is different from IIS ASP.NET website. IIS SharePoint Website registers an extra SPRequest module which fetches the data from SharePoint content database. When you request / , it will always try to pull this data from the SharePoint Content database.
In your case, where you have changed the SharePoint-80 website to point to wwwroot, you have essentially removed SPRequest module from the pipeline. That's the reason you get the error, because its not able to pull the content from the database.
You should do the other way around. Change main site to Sharepoint site, and let your other asp.net application/site to be subsite of sharepoint.
You cannot do that. Simply because you're trying to encapsulate a cloud-based system into an internal IIS folder structure.
You can not add Sharepoint online page in an iframe because of the same origin policy that most of the sites on internet adopted this days. This is mainly for security reasons to avoid from web attacks like Clickjacking and XSS.
You can not add Sharepoint online page in an iframe because of the same origin policy that most of the sites on internet adopted this days. This is mainly for security reasons to avoid from web attacks like Clickjacking and XSS.
If you want to display the content of the sharepoint online into different domain, than try to use provider hosted app in windows azure or develop a Napa sharepoint hosted app which can make cross domain requests in REST or ajax
I want to build ASP.NET MVC-3 web site that will have some reports.
mainly the web site consists of some reports that search data.
The reports will be available internally inside the company and externally.
internal staff has more reports, and even with the shared reports, will have more data to display and look for.
What are the best approach to do that.
internally the security will be based on windows-authentication.
Externally will be on active directory.
Authentication is about checking you are you say you are. Your question is about authorization. Which rights you have, what you can see or not.
I would use different roles for internal and external users. Based on your role you have more or less rights.
i have a web site that uses forms authentication. the problem is that i have the site installed multiple times on the same production servers because i need to have a few different login pages (based on the domain in this case). after the domain specific login page, the rest of the site is the same. obviously, this requires a lot of maintenance as each new version has to be installed multiple times on the server (with varying the login page in the web.config file).
so i thought is there a way to install the site on 1 folder on the disk, have a web site on the IIS take in all the needed domains and make some http module (or some other solution) in which i could give it a list of domains and the forms authentication for that domain. this way make the login page used by each site change according to the domain while still having only one site to maintain on the server.
Thanks
Dani Avni
I have seen this go a number of ways and a lot of it depends on how you have things setup in IIS.
If all domains are on the same IIS website the most common solution would be to create a httpmodule, or even an actual .aspx page, that loads configuration and based on the requested URL send the user to the right login page. You could even do a "Server.Transfer()" if you want the users URL to stay the same. Then in the web.config you still set a single login page. Just make sure that each other login page allows anonymous users access.
If all domains are separate IIS sites, i would recommend at that point just maintaining different copies of the sites. But the real question is why you need different logins.
My workplace has a couple of web applications that do exactly what you are trying to describe. There are a couple of approaches we have used, depending on the situation.
The more common approach we use is to have all the actual sites on IIS point to the same directory. The logic for the login gets the URL, determines which client site is being requested, and takes that into account on login. The actual login page is the same for all client sites, though, so it's just determining which database to use.
If you want to do anything fancier than that, another approach we have used is to create our own MembershipProvider, at which point you can basically do whatever you want. You should have access to HttpContext.Current if your class is being called by the ASP.NET authentication provider (you would set the membership provider in Web.config to your provider).
I would like to create a sandbox area on my hosting provider that only the client can see. For example the production website would be at www.domain.com. However, would it be possible to create a sandbox version of the website at www.domain.com/sandbox and only provide access to the client?
If so, what is the best method? Do I manually have to create a login page etc in the sandbox folder? Or, can I publish the test website in the sandbox area and restrict access through my hosting provider?
Generally a sandbox/staging/test version of your production site would be a complete duplicate of your production deployment, not just the login page.
You'd have a separate copy of the application and the database, and then serve it via another hostname/IP address or on an entirely different machine.
For instance, you could have www.domain.com and test.domain.com, each with the own isolated version of the software. This way your client can play as much as they want in the sandbox without fear of damaging the production environment.
To restrict access you could use access control lists in IIS to restrict the sandbox to a specific ip address (or range), or enable basic support on it with a username/password required security.