locked
Unable to access published lightswitch website RRS feed

  • Question

  • I have a number of lightswitch applications, that are running on my development machine, and a test IIS server. I have two different subscriptions, downloading the profile etc from the azure subscription, each of these displays the website as being published without any errors. But when navigating to the URL I get HTTP 403 Forbidden!!!

    I am using Visual Studio 2012, with Update 4, the latest Azure Toolkit, in fact every update has been applied.

    Any Ideas?

    The Certificate is the one provided via the profile(?) I am using a SQL Database in Azure, in the same region, the tables have been created and can be accessed via SQL Server Management on the desktop.

    I have been trying to get this website running in Azure for the past month or so, on and off, but I am now getting extremely frustrated, I have followed every tutorial out there for publishing to Azure (for Lightswitch). I have trawled the web for similar problems and tried the suggestions.

    What Am I doing wrong?

    Unwilling to commit anymore money to get support, this should work surely. Will be dismissing azure as a platform if I cannot get this working.

    I have tried publishing from another machine using both VS2012 and VS2013, same result.

    I welcome any suggestions

    Steve  

     
    Saturday, January 18, 2014 4:23 PM

Answers

  • After a lot of research, testing and trying to get this to work, I found this forum post: http://social.msdn.microsoft.com/Forums/vstudio/en-US/6df0ea95-8501-42ae-83ac-01faaf737300/published-app-does-not-work-after-upgrade-to-vs2013?forum=lightswitch

    Tried the website with the \client as the last part of the URL, and I was able to download the file etc....AT LAST!!!

    Before I found this, I removed the requirement for "Access Control" from the project commented out the screen "canrun" code that I had created, the application ran, with all screens available and I entered some test data, it was inserted into the database, and somehow the aspnet_* tables had data in them (where did that come from?).  Oh well, I cannot waste more time to try and find out what step created this data, the last used stamp in the user table indicates that this occurred a few hours back !

    I have now reinstated the forms authentication and tried to login, the application is on the desktop, but I get an error about cookies, which I may investigate or I may not for the moment. There is only one user of this application for the moment, so I am not too concerned about the security of it for a short while, Azure has the IP settings only for my desktops and the desktop that the user will be using. This should suffice for a very short initial period.

    I will try and solve the cookie error at some stage in the next few days, and then repost hopefully with an end to this saga, sorry if I have bored anyone.

    Steve

    • Marked as answer by Haixia_Xie Monday, January 27, 2014 2:55 AM
    Wednesday, January 22, 2014 4:53 PM

All replies

  • Hi,

    Can you tell us in which step you get an issue when publish the app to Azure website? Take the steps in this blog for example:

    http://blogs.msdn.com/b/lightswitch/archive/2012/06/07/publishing-lightswitch-apps-to-azure-with-visual-studio-2012.aspx

    Monday, January 20, 2014 11:32 AM
  • Yes the 403 happens once the site has been published, and a window is created in IE to display the azure management application, then when using the link for the website, it opens another windows and displays the 403 error. I used the instructions on the page indicated above to publish the website.  Here is the build output from the publish activity.

    ------ Build started: Project: Client, Configuration: Release Any CPU ------

      Client -> F:\BlueFlag\Bluenrg\CRM\CRM\Client\Bin\Release\Blu NRG Prospector.Client.dll

      Begin application manifest generation

      No changes detected. Application manifest file is up to date

    ------ Build started: Project: Server, Configuration: Release Any CPU ------

      Server -> F:\BlueFlag\Bluenrg\CRM\CRM\Server\bin\Release\Application.Server.dll

    ------ Build started: Project: CRM, Configuration: Release Any CPU ------

    ------ Publish started: Project: CRM, Configuration: Release Any CPU ------

    Signing Xap file...

    Transformed Web.config using F:\BlueFlag\Bluenrg\CRM\CRM\Server\Web.Release.config into obj\Release\TransformWebConfig\transformed\Web.config.

    Start Web Deploy Publish the Application/package to https://waws-prod-db3-001.publish.azurewebsites.windows.net/msdeploy.axd?site=ecocrm ...

    Adding ACL's for path (ecocrm)

    Adding ACL's for path (ecocrm)

    Updating file (ecocrm\bin\Application.Server.dll).

    Updating file (ecocrm\Client\default.htm).

    Updating file (ecocrm\Client\web\CRM.Client.xap).

    Updating file (ecocrm\web.config).

    Adding ACL's for path (ecocrm)

    Adding ACL's for path (ecocrm)

    Publish Succeeded.

    ========== Build: 3 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

    ========== Publish: 1 succeeded, 0 failed, 0 skipped ==========

    Furthermore the database tables are created, but the user (Application Administrator) was not created, in fact all tables are empty except the aspnet_SchemaVersions table. When I previously published this in another subscription, the database was populated with the Application Administrator, so it seems no step forward and one step backwards.
    • Edited by rouses Monday, January 20, 2014 1:41 PM
    Monday, January 20, 2014 1:14 PM
  • For 403 errors, Turn on FREB trace on the portal would be great help.

    Tuesday, January 21, 2014 2:39 AM
  • Ok, I don't know how to do that so I switched everything on, that I could find to diagnose the problem;

    I do not know how to get to the file system to access these logs. I have done some searching, but I am still "in the dark". Will continue researching, but will have to research another strategy other Azure very soon, time constraints dictate this. I thought it would be easy to create a website from a Lightswitch application after viewing videos and articles.

    I would appreciate any help. Surely I am not the only person in the world having this issue!

    ----------------------------------------------------------------------------------------------------------------------

    downloaded the logs using the azure tools in VS2012, here is the http:Raw Log

    #Software: Microsoft Internet Information Services 8.0
    #Fields: date time s-sitename cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) cs(Cookie) cs(Referer) cs-host sc-status sc-substatus sc-win32-status sc-bytes cs-bytes time-taken
    2014-01-21 14:03:11 ~1ECOCRM POST /diagnostics/settings X-ARR-LOG-ID=8ea450ba-0db3-43f6-abc1-b31836c65d7e 443 - 70.37.162.148 Azure-Portal/3.15.00298.7 - - ecocrm.scm.azurewebsites.net 204 0 0 401 2356 203
    2014-01-21 14:11:49 ECOCRM GET / X-ARR-LOG-ID=50d7a316-8921-450f-961c-0ef11f551d57 80 - 86.180.103.41 Mozilla/5.0+(Windows+NT+6.1;+WOW64;+Trident/7.0;+rv:11.0)+like+Gecko - - ecocrm.azurewebsites.net 403 14 0 417 611 6983
    2014-01-21 14:12:23 ~1ECOCRM GET /jobs/continuous/ X-ARR-LOG-ID=08f0d118-56dc-48d0-96e7-3c094e615da6 443 - 70.37.162.148 Azure-Portal/3.15.00298.7 - - ecocrm.scm.azurewebsites.net 200 0 0 451 2102 2046
    2014-01-21 14:29:40 ECOCRM GET / X-ARR-LOG-ID=20d9c9c9-f0e1-43a2-8cee-fb21bcb884f7 80 - 86.180.103.41 Mozilla/5.0+(Windows+NT+6.1;+WOW64;+Trident/7.0;+rv:11.0)+like+Gecko ARRAffinity=c4b612d127fedfc28568bb016d15d3950d0c8fac90901a2863e9590aa8e9f0d3;+WAWebSiteSID=0e5cd79c72ea45f6b1cfc054ec254ff6 - ecocrm.azurewebsites.net 403 14 0 417 744 2780
    2014-01-21 14:32:10 ~1ECOCRM GET /jobs/continuous/ X-ARR-LOG-ID=d0ade69e-fba8-44d2-9119-08f7254a2d9b 443 - 70.37.162.148 Azure-Portal/3.15.00298.7 - - ecocrm.scm.azurewebsites.net 200 0 0 461 2088 62
    2014-01-21 14:32:12 ~1ECOCRM GET /diagnostics/settings X-ARR-LOG-ID=b7d19806-c68f-4b9e-b5d3-7a0ba4c6b535 443 - 70.37.162.148 Azure-Portal/3.15.00298.7 - - ecocrm.scm.azurewebsites.net 200 0 0 630 2095 203
    2014-01-21 14:42:42 ECOCRM GET / X-ARR-LOG-ID=c3d3db4c-e58a-45b3-abf1-f4a7f1428125 80 - 86.180.103.41 Mozilla/5.0+(Windows+NT+6.1;+WOW64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/30.0.1599.101+Safari/537.36 - - ecocrm.azurewebsites.net 403 14 0 417 694 31
    2014-01-21 14:42:42 ECOCRM GET /favicon.ico X-ARR-LOG-ID=b1fa0513-2aad-470f-a178-7fef285c91d4 80 - 86.180.103.41 Mozilla/5.0+(Windows+NT+6.1;+WOW64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/30.0.1599.101+Safari/537.36 ARRAffinity=c4b612d127fedfc28568bb016d15d3950d0c8fac90901a2863e9590aa8e9f0d3;+WAWebSiteSID=04d9b127e32a4d149aef8ea3b3d8a889 - ecocrm.azurewebsites.net 404 0 2 465 778 15
    2014-01-21 14:52:21 ~1ECOCRM GET /diagnostics/settings/ X-ARR-LOG-ID=d455752f-7666-4556-bcd8-508e41dfb91a 443 - 86.180.103.41 - - - ecocrm.scm.azurewebsites.net 200 0 0 630 729 78

    And one of the error pages from the log :-

    HTTP Error 403.14 - Forbidden

    The Web server is configured to not list the contents of this directory.

    <fieldset>

    Most likely causes:

    • A default document is not configured for the requested URL, and directory browsing is not enabled on the server.
    </fieldset>
    <fieldset>

    Things you can try:

    • If you do not want to enable directory browsing, ensure that a default document is configured and that the file exists.
    •            Enable directory browsing using IIS Manager.          
      1. Open IIS Manager.
      2. In the Features view, double-click Directory Browsing.
      3. On the Directory Browsing page, in the Actions pane, click Enable.
    • Verify that the configuration/system.webServer/directoryBrowse@enabled attribute is set to true in the site or application configuration file.
    </fieldset>
    <fieldset style="width:485px;height:116px;">

    Detailed Error Information:

    Module    DirectoryListingModule
    Notification    ExecuteRequestHandler
    Handler    StaticFile
    Error Code    0x00000000
    Requested URL    http://ecocrm:80/
    Physical Path    C:\DWASFiles\Sites\ecocrm\VirtualDirectory0\site\wwwroot
    Logon Method    Anonymous
    Logon User

       Anonymous

    </fieldset>
    • Edited by rouses Tuesday, January 21, 2014 3:08 PM
    Tuesday, January 21, 2014 2:39 PM
  • I should add that this is a "desktop application", but I have tried with the settings as a "web application", went into file view and set a default document. Same problem;

    2014-01-21 14:52:21 ~1ECOCRM GET /diagnostics/settings/ X-ARR-LOG-ID=d455752f-7666-4556-bcd8-508e41dfb91a 443 - 86.180.103.41 - - - ecocrm.scm.azurewebsites.net 200 0 0 630 729 78
    2014-01-21 14:53:20 ~1ECOCRM GET /dump/ X-ARR-LOG-ID=188b6652-b9d3-4793-9495-054b14fac1b9 443 - 86.180.103.41 - - - ecocrm.scm.azurewebsites.net 200 0 0 15583 639 93
    2014-01-21 14:59:36 ~1ECOCRM GET /dump/ X-ARR-LOG-ID=3792f1f5-d30c-4621-9952-9a8e5e38066b 443 - 86.180.103.41 - - - ecocrm.scm.azurewebsites.net 200 0 0 15792 639 109
    2014-01-21 15:20:40 ECOCRM GET / X-ARR-LOG-ID=78a31c51-d355-42d1-b286-226614073dee 80 - 86.180.103.41 Mozilla/5.0+(Windows+NT+6.1;+WOW64;+Trident/7.0;+rv:11.0)+like+Gecko ARRAffinity=c4b612d127fedfc28568bb016d15d3950d0c8fac90901a2863e9590aa8e9f0d3;+WAWebSiteSID=0e5cd79c72ea45f6b1cfc054ec254ff6 - ecocrm.azurewebsites.net 403 14 0 417 744 3609

    Also I have created a Single Page Application "Hello World" and published that, same response (403), will try on the other machine tomorrow, and also VS2013 on that machine.

    Tuesday, January 21, 2014 3:26 PM
  • Created a website from the gallery, a blog using BlogEngine.Net 2.8 This was accessible, not sure if this step helps me in my quest though.

    I have the additional issue of not having the "Application Administrator" set-up in the database, although all tables are created. Will continue to investigate.  

    Tuesday, January 21, 2014 3:45 PM
  • Created an MVC Application and published it, this appeared to work, it now looks as if it is the light switch application itself. Don't really want to rewrite this using MVC but may have to.
    Tuesday, January 21, 2014 4:06 PM
  • Created a blank lightswitch application using VS 2013, published it and had . . . Http: 403.

    So it would appear I cannot publish LightSwitch applications to Azure.

    Does anyone have any ideas as to why?

    Thank you in advance for any help.

    Tuesday, January 21, 2014 4:53 PM
  • Tried the following:

    1. I have now created a new project on a "clean" Windows 8.1 machine.
    2. New installation of VS 2013.
    3. Ran the project on the Pc and it worked.
    4. Published to Azure.

    Same error, 403!!!

    So it looks like I cannot publish lightswitch projects to Azure at all, has anyone else had a similar problem, or indeed does anyone have any solution, it looks like I have to either set-up a server on the internet and install the website on there for the intended audience or rewrite the project using MVC.

    I also cannot understand the fact that the database does not get populated with the "application administrator" does anyone have any suggestions for resolving this.

    Here's hoping that someone has some inspiration.  

    Wednesday, January 22, 2014 11:20 AM
  • Have now changed the publishing "profile", setting the database to be a sqlserverexpress one, this created every table, the same as in azure, it also created the Application record in the DB unlike Azure, but it did not create the Application Administrator (user) exactly the same as in the azure publish.

    I think my "problem" relates to this lack of the Application Administrator record and the other "base" tables such as Application ID. I tested publishing with the "Contoso Construction" sample, and exactly the same issues, with the DB etc. As I had published this to another subscription and tested it, which worked as expected, it has to be something that has changed with the publishing method and/or Azure SDK etc, the contoso sample was published before these were installed.

    Maybe I should navigate to another forum "Lightswithc Publishing?" to continue my attempt to get this working. Will add details if I resolve this, and/or additional steps I have taken.

    Steve 

     
    Wednesday, January 22, 2014 1:31 PM
  • After a lot of research, testing and trying to get this to work, I found this forum post: http://social.msdn.microsoft.com/Forums/vstudio/en-US/6df0ea95-8501-42ae-83ac-01faaf737300/published-app-does-not-work-after-upgrade-to-vs2013?forum=lightswitch

    Tried the website with the \client as the last part of the URL, and I was able to download the file etc....AT LAST!!!

    Before I found this, I removed the requirement for "Access Control" from the project commented out the screen "canrun" code that I had created, the application ran, with all screens available and I entered some test data, it was inserted into the database, and somehow the aspnet_* tables had data in them (where did that come from?).  Oh well, I cannot waste more time to try and find out what step created this data, the last used stamp in the user table indicates that this occurred a few hours back !

    I have now reinstated the forms authentication and tried to login, the application is on the desktop, but I get an error about cookies, which I may investigate or I may not for the moment. There is only one user of this application for the moment, so I am not too concerned about the security of it for a short while, Azure has the IP settings only for my desktops and the desktop that the user will be using. This should suffice for a very short initial period.

    I will try and solve the cookie error at some stage in the next few days, and then repost hopefully with an end to this saga, sorry if I have bored anyone.

    Steve

    • Marked as answer by Haixia_Xie Monday, January 27, 2014 2:55 AM
    Wednesday, January 22, 2014 4:53 PM
  • I do not consider this as answered, primarily because the "access control system" was NOT published to the azure web site, therefore the web site is not working as "expected". I have entered a post on the Silverlight forums, and hope that one of these forums does provide with the answer, so that I can use the web site as envisioned, if the Access Control does not get "populated" then this is a serious flaw/issue for me. 
    Monday, January 27, 2014 9:25 AM