I deployd release with some script portlets applications on more managed pages to production as is described here:
http://www-01.ibm.com/support/knowledgecenter/SSHRKX_8.5.0/mp/deploy/dep_deploy.dita?lang=en
Portlets have security restrictions to authentificated users. After I first time logged in its all OK. However when I try to click on another page on that portal I'm redirected to login page again.
I investigated it in web browser console. There were changing JSESSIONID in cookie every GET method:
...sessionCode=-776125765; JSESSIONID=0000f7VRxv0SelqdHKq_cdSkfwr:-1;...
...sessionCode=-776125765; JSESSIONID=0000CgNGvCB89PS5pam1KA4q1jM:-1;...
...sessionCode=-776125765; JSESSIONID=0000LzkNhV2ycEx9irw8ueRJeV6:-1;...
But in source portal it stay the same:
...sessionCode=-776125765; JSESSIONID=0000S9uf4WFCR1-HbNKvK2oRwVp:-1;...
...sessionCode=-776125765; JSESSIONID=0000S9uf4WFCR1-HbNKvK2oRwVp:-1;...
...sessionCode=-776125765; JSESSIONID=0000S9uf4WFCR1-HbNKvK2oRwVp:-1;...
Have someone some ideas how to fix it?
Do you have any embedded links to other sites/applications in the same domain ?
May be that application is changing the JSESSIONID cookie - causing the portal app to invalidate.
Usually if we have multiple servers running on the same system or domain - we change the name of the JSESSIONID.
Related
So we have this web application running, but we wanted to make a Teams app (personal tab) from it. We used App Studio to create the app (manifest and all), but when running it from the sidebar we won't get past the login screen. On successful login, you get redirected back to the login page (everything happens on the same domain).
But when we tried to run the "app" as a tab within a group, this worked. So we need to find out why this doesn't work when we run it as a Teams "app".
Any ideas would be appreciated :)
The problem was that since it's running inside an iframe (in practice), the cookie set by ASP.NET State needs to state SameSite="None" and Secure="true".
Applications that use <iframe> may experience issues with sameSite=Lax or sameSite=Strict cookies because <iframe> is treated as cross-site scenarios. - https://learn.microsoft.com/en-us/aspnet/samesite/system-web-samesite
So I had to upgrade the .NET Target Framework to 4.7.2, and make the changes stated in this document: https://learn.microsoft.com/en-us/aspnet/samesite/system-web-samesite
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/
We are a software dev company company with a product that is deployed at our client's site. Recently, we started seeing an issue with our login in conjunction with Siteminder.
They have Siteminder turned on but we are not integrating with it for SSO. They get to our login page just fine. When a user inputs their login credentials our application returns a login error and does not allow them to login.
Upon further investigation, we found that our login process is receiving 2 different requests! One with the correct username and PW and another request is blank username and PW. As soon as we turn Siteminder off, it works correctly.
We are not sure if this is an issue in our code or with Siteminder's setup. We have other instances of the application that work correctly. We did no code changes to integrate with SM when we first deployed and it was working fine before. We sent a code update and then it started not working. It all points to us but we cannot find it in the code. Any help here would be great! We are not sure how SM really works with this.
This probably is not something that Siteminder is causing. Did you trace the JS requests to see if there are two submits being done on the page
Generally WE Disable the webagent to remove the siteminder component from the infrastructure. if the end user is able to access application without the siteminder component the the problem relise on siteminder part.
and if user is facing an issue while accessing the an application without the siteminder composts . then there is no issues on siteminder components.
I recently decided to change from using Windows Authentication for my internal web applications to Forms Authentication. I've not used the latter very much and one site explained you have to enable both Forms and Anonymous for this to work. The idea is to verify user passwords against an active directory then grant them access accordingly. I had this working just fine locally and when publishing to IIS 7.5 it still worked. It was just a basic Visual Studio project that would redirect to our homepage.
The problems arose when I tried accessing this same project securely with https, I included the full domain and it would load the new login page but when I clicked login it would do nothing. Since then I've scoured the web and found numerous mentions of this and that and tried many of them to no avail.
It was only later I created a blank project with a single button and one line of the code on the page to see if a post back had fired. After publishing I only enabled Anonymous Authentication in IIS and browsing to this basic test app using http when you clicked the button, false on the page changed to true - indicating a post back. Yet with https it just remains false. I think this may be why the active directory login wasn't working as it too had Anonymous enabled.
I'm still pretty new at the secure side of things but with the details passing over I have to use a secure connection just for the login then it can redirect to the usual applications we use internally.
I'd appreciate any thoughts you may have regarding this.
Thanks!
We use this configuration (anonymous IIS access, forms authentication, and https) successfully all of the time.
There are three things that you should do to track this issue down:
1) Verify that there are no javascript errors in the page that break the button (i.e. a javascript file not being delivered to the page)
2) Check the windows event logs for exceptions from asp.net/iis.
3) Install and run fiddler, select Fiddler Options... from the Tools menu, click on the HTTPS tab and ensure all of the checkboxes are checked, then run your website and look at the requests and responses, particularly when you press the button.
I just installed IIS7.5 on my brand new windows 7 box.
I created a new site using .NEt 2.0 DefaultAppPool, and set up permissions on the database and on the disk for that DefaultAppPool user.
All seemed good, until I deployed and visited my site http://localhost:9000
The page itself worked and returned html, but all static content and scripts were redirected to the logon page.
e.g.
/Scripts/jquery-1.3.2.min.js ==>/logon?ReturnUrl=%2fScripts%2fjquery-1.3.2.min.js
This same code when I publish to a live website works flawlessly and is in fact production code.
I had this working fine in Vista IIS7 too, but obviously I haven't set up something properly.
Anyone know how to fix this?
Any help is greatly appreciated.
Regards,
CV
UPDATE: all URL requests are being redirected to logon page
so if i enter http://localhost:9000/ into the browser i go to http://localhost:9000/logon
which is specified in my config file.
What on earth is deciding my visits should be redirected there? the homepage doesn't have the AUthorize attribute on it.
Ensure that forms and windows authentication are not both set, it should be one or the other - IIS may even give you a warning about it. I was having some strange static file redirect issues and this is what turned out to be the problem.
See this answer: Why is my style sheet redirecting me to login?
Set Anonymous Access to use the Application Identity instead of IUSR in IIS.
I faced the same error. To solve this issue, you should enable Anonymous Authentication, which will run under the App Pool identity instead of IUSR in IIS