This is the first time i am doing the deployment from my side and am new to AWS. I have a project deployed on Amazon AWS server for testing purpose. I have set the domain name as: https://domain.biz
I have a login page here where once the user logs in successfully i am setting the userId in the session and navigating the user to dashboard.
In the dashboard i have added a function to check whether session set with value of userId. If the session is not set then i am navigating user back to login page. This is to block the unauthorized access to site.
I am facing problem here. when i was working with the server before adding ssl it is working fine.after https://domain.biz session is working one page.and http://domain.biz works fine. When i have added domain to https then the session is not working. What is the problem here with AWS? Am i missing anything.
Check this : Session lost when switching from HTTP to HTTPS in PHP
Since codeignitor is in php, I suppose this thread could solve your issue.
Related
I'm trying to run a python script that interacts with the GMail Api on AWS EC2. Said script SHOULD either process the authenticated inbox or ask for authentication if the token doesn't exist. This authentication normally takes the form of opening up a browser window. This works on localhost but doesn't work on my EC2 instance.
I've tried running a webserver using Flask (accessible through its public IP) and having the call to the script be the result of clicking a button. When I do this, I get other interactivity from the Flask script and the authentication URL prints out on the CLI, but I'm not redirected.
I've tried just running the script from the CLI, but that obviously doesn't work. That last one might've just been desperation and/or wishful thinking.
EDIT: Info - The URL seems auto-generated so I don't know it ahead of time.
I'm trying to understand the process of login to a website using the Network tab on Google Chrome because I have to use that process for autenticate accounts on an mobile application.
The login is completed when I reach the page "HomepageStudente.do", but I don't understand how to replicate all this on Postman. I've tried to do this:
Right-click on the SSO request
Copy as Curl (bash)
And it seems to work, but when I do the same thing with the second request (POST) I get a different message compared to the one on the Network tab.
Those 3 calls are based on automatic redirect by the browser, and I don't understand how to replicate it on Postaman. Is this possibile to do? Any other suggestion on how to use those requests for authenticate an account outside the website (example mobile app)?.
Thanks
I have deployed my nodejs app on aws ec2 and its working fine while I am using it on the browser normally. But when I am accessing it from inside my Shopify app then it is showing that the request has been blocked by an extension.
I tried to access it in incognito mode also but got the same result.
Can someone please help.
Shopify blocks all http requests. You may want to check if you are loading any URL in http
Update -
AWS provides secure URLs. Find it and use it instead!
If users authenticate with Auth0, get a token, and then send that token on every request, what would be the point of ELB sticky sessions? I'm assuming sticky sessions are not necessary with token-based authentication and that the same user could safely hit difference EC2 instances on each request without any strange behavior. Is that correct?
Generally speaking, yes. If you aren't saving session state on the application server itself then you can safely hit different servers for each request and not miss a beat.
However, one thing to consider is what happens during application updates?
Let's say you have a website. Then you update that website with a new menu button which directs users to a new page. If you aren't using blue/green deployments, then at some point in the update process you will have two versions of your app running. So imagine the user goes to your website home page which gets directed to version 2.0. The user clicks the newly added button. This request is fielded by a version 1.0 server and now you've got a 404 error because it has no idea about the new page.
You can use sticky sessions not strictly for session state, but for application version consistency during updates.
I'm new to the SSO world and I've recently installed WSO2 Identity Server 5.0 and done my best to hook in a service provider but I just can't seem to figure out how to make SSO happen.
Here is my current situation and goal:
I have a MojoPortal website where a user can log in. From there, the user can click a link to our FTP site powered by GoAnywhere. We want the user to be logged into the FTP site just by clicking the link instead of having to log in to it as well. The FTP site is SAML2 enabled so I chose the WSO2 ID Server to give SSO capabality between my mojoPortal and goAnywhere sites.
Here is what I think needs to happen - sanity checks welcome:
1. User clicks to access the FTP website and my mojoPortal website needs to create a SAML request and send it to the ID server. I can't seem to get a grip on doing this from an ASP.NET page.
2. ID server gets the request and validates it (you can test the request in the "SAML Request Validator" tool in the WSO2 console, right?)
3. ID server sends a response to the GoAnywhere FTP site which can be simulated with the SAML Response Builder tool in the ID server console.
4. The FTP sites says either OK or NO to access.
5. Not sure what happens next - how does the user get redirected to the FTP site.
So I have big issues: I don't understand the flow in great enough detail and I'm also having difficulties in getting the technologies to work together.
Any comments / help at all are greatly apprciated!
MojoPortal website - is this SAML2 Web Browser based SSO supported? If yes, then the solutions is clear.
You just have to register your 2 sites in WSO2 IS as SPs.
Then what will happen is , once the user log-in to the MojoPortal website, he user will have a live login session, therefore once he clicks on the FTP site, he will be able to access it without having to log-in again.
Hope this clarifies your doubts.