I've trying to add a messageboard to my Codeigniter web site. Everything has gone well except for one little part: I'd like my log in from the main site to carry over to the messageboard. Since the messageboard is not able to run in Codeigniter, I made a subdomain to run the messageboard in. This means that the main site and the messageboard do not share cookies. The messageboard is Phorum-powered, so there's a hook that I can use to sign in if I have the user_id of my user. In other words my problem basically boils down to being able to run a function on one domain that can get the user_id variable stored in the session of another domain.
Here are things the I've tried:
Setting up a controller in codeigniter that uses ci->session to echo the user_id. Then in the messageboard, I used CURL to fetch me the output of the codeigniter controller. This doesn't seem to work because CURL doesn't carry cookies or sessions or something, so codeigniter can't access it's session when called through CURL.
Same thing but with file_get_contents. File_get_contents is disabled on my server.
I'm pretty much out of ideas. Does anyone know a function I could write that would get me a CI session stored user_id from a different domain?
Here are two things you can try:
1) host the forum in a subdirectory of your code igniter project. So your two websites will have the url http://mysite.com/ and http://mysite.com/forum. Now that they share the same domain, you can access the session.
2) In your forum login page, display the message "auto-signing in". On that same page add an iframe in the html with the src="http://mysite.com/autologin/tokenid", but hide it with css. The autologin page will have CI session information, which you can temporarily make available to the world via a hard to guess tokenid and by echoing $_SESSION['user_id']. Remember to expire this page when you are done with it. Then refresh the forum's login page and use CURL to grab the publicized session information at http://mysite.com/autologin/tokenid. This is full of security flaws, so do it only as a last resort.
Related
We have an issue with a asp.net core 3.1 MVC application. The application is using the built in asp.net Identity feature. The application is working well for existing users. If you hit any [Authorized] route, you are redirected to the login page as expected.
However, rather than have a registration process in our app, for new users, we onboard them via Stripe Checkout. Upon successful payment, stripe redirects to a specific route in our application /conversion/success/{sessionid} where sessionid is the Stripe session. This action is marked as [AllowAnonymous].
We then pull the necessary customer details from Stripe, create a user in our repository via UserManager<T>. We then call SignInManager<T>.SignInAsync() to sign in the new user, before redirecting the new user to the [Authorized] home page.
This process works perfectly when running locally on our test machines. Also, when running on our production server (Azure App Service) it also works perfectly when we hit the route manually through the browser.
However, when we actually run the process through Stripe, complete a payment and let Stripe redirect the customer, we get a strange behaviour.
The conversion route is hit, the user record is created, the sign in process completes but upon redirection to home page, the authentication middleware takes over, says it's not authenticated and redirects to the login page.
Just to compound matters further, if you then simply type in the home page route in the browser, the user is in fact logged in exactly as expected and the application works perfectly.
Using Fiddler to intercept the calls and look at headers, etc. we can't see why there would be a different behaviour when coming from Stripe as opposed to typing directly. We've even tried redirecting from a different website to our registration process and that works as expected too.
Any idea why we are seeing this behaviour?
---- Update ---
If, rather than redirect to home page at the end of the onboarding process, we simply show a simple View with an anchor link to home page, the user can then go to home page as expected.
Is it possible that you're rendering the page before authentication has been completed? Since UserManager uses a cookie to establish the user's session, authentication needs to complete before any response headers or body is set so that the Set-Cookie header can be sent in the response.
Based on what you described it sounds like the user is hitting the homepage after the redirect without having the authentication cookie. Where I'd start debugging this is by using your web inspector with "Preserve log" turned on and going through the Stripe Checkout process. Then, inspect the headers sent to the browser when you land on the redirect page & make sure the authentication cookie is set.
Between requests to Stripe and SignInAsync it seems possible that there might be a missing await, so the redirect is happening before the authentication context is updated. Hard to say more without seeing your code!
I am novice in Jmeter, just started to know its inner functionality. I am stuck in a problem. I have to hit multiple urls (only search id) is changed so in "HTTP Request" i have placed "/build-4.4.10.0/?earchId=${ID}&Application=sc&IsSearchLink=TRUE"
I am providing session key and that search id through csv file. Problem is though its going to the link but redirecting it to login page, and i do not know how to create users on run time and assign to that each URL.
I have 200+ URLS, what should i do, please guide
Thanks
If your application needs any login authentication and/or cookies, then you will need to add the Cookie manager for maintaining the session, else application will not be able to maintain a session and it will throw the user out of the application, then redirecting it to the login page.
You can refer to the below mentioned links for more information about cookie manager.
https://sqa.stackexchange.com/questions/13966/jmeter-http-cookie-manager/13975#13975
http://jmeter.apache.org/usermanual/component_reference.html#HTTP_Cookie_Manager
i'm trying to create a web app with back and front end separated, so there is two project here. The reason is there is a plan in the future to create mobile version as well, so i made it decoupled.
Just FYI the back are created with PHP using laravel4 and barryvdh CORS
and the front end are created purely with angularjs and bootstrap.
The current situation is that i create a rest API in my back end app to do login, auth, and logout.and in the front end i have 2 pages, which is login and index page.
Login page are composed of username, password input field and submit button,
when user click submit button, it will call the login rest API from the back end and i expect it would persist cookie to the front end page if login success, but it doesn't (because of cross origin policy, i've research as much).
The question is, is there any way to set sessions across domains now it is 2014, where any article i found are from 2012 older. If it's not possible, what's the easiest way to persist session across domain besides OAUTH2 and openID (because their learning curve are just too steep, the application i'm creating are just small app)
Thanks for your assistance.
what I have done so far to work with cross-domain sessions is to create a "passport" service on a another domain and validate & handle the session from the there.
For example...
domain1.com has webserver1
domain2.com has webserver2
passport.com has webserver3
Whenever I connect either to domain1.com or domain2.com I'm including a line at the very top of the script index checking on passport.com/check.php whether there's a browser session already initialized under the name of "PASSPORT", if so, I finish the checking on passport.com and let the script on domain1.com or domain2.com to do their stuff.
In case the browser session wasn't initialized, the check.php will redirect the index via header() to the login.php page. This will validate against LDAP and if binding the user is OK then the browser session is initialized with the name of "PASSPORT" and including all the fields I need furthermore to validate the user and its accesses. Ref back to the index once is done.
When the user goes from domain1.com to domain2.com (or the other way around) the script included at the top of each index will check the session again all the time, taking the user to the login script or letting him access the required site.
As additional checking you can create the session and add variables such as "valid until", "access level", etc.
Hope this helps and if you need further clarification let me know.
Best,
Emiliano.
I will explain my problem. I need to know if the steps below are correct:
The user enters their login details and these get submitted to the php server. If these are correct, I want to use the php code to start a session. However, because this is a mobile device I will be using html5 session storage. Now, my mobile website is all ajax based with no page reloads. So if the user submits the correct login credentials, I make an ajax response back to the user with what information? The SID/session_id of the session_start? Then, on the mobile device I place this session_id into the html5 session storage?
So, if these steps are correct, when the user then navigates around the website they are now logged in. And if they want to do something e.g. access a private page this creates an ajax request to the php server... this is where I am stuck. I assume that in this ajax request I send the session_id from the html5 session storage object, how does the php server use this id to prove the user is authentic? Presumably I need some kind of if statement and if it's not satisfied, send an ajax response back which my javascript will interpret as redirecting the user back to the login screen.
Many thanks if anyone can help me, it will be much appreciated as I am very stuck.
Note that cookies are not an option...
You could theoretically use HTML5 local storage to store the session ID, or transmit the session ID as a GET parameter in every request and pass it manually to PHP using session_id(), but I can't see the benefit. You might as well rely on cookies for this - they will be transmitted in Ajax requests.
Updated with clarifications
Hello,
When our users go to http://mysubdomain.server.com/login they get redirected to https://secure.server.com/login?subdomain=mysubdomain. So the actual login page is located on the secure.server.com subdomain.
The problem is that if the user logs in with the credentials meant for subdomainA and tells Firefox to remember the password, the browser will autocomplete the login form even if the user visits the login page meaning to log into subdomainB.
Firefox assumes that the login form on secure.server.com/login?subdomain=subdomainA is the same with the one on secure.server.com/login?subdomain=subdomainB.
At first, I thought Firefox remembers passwords based on a combination of the URL and the name attribute of the form, but I've tried changing the name based on the subdomain (name="login-<subdomain_name>"), and it still doesn't work.
How can I make Firefox remember passwords for subdomainA and for subdomainB separately, and not together?
I couldn't quite decipher what your setup is, but you can enable login manager debugging and check what Firefox does. You can also inspect signons.sqlite in your profile to see what pieces of data are stored with the login.
I thought that for web forms it keyed off the form's submit URL, but my memory is shady on this.
[edit]
source (nsLoginManager.js) says it only uses the form's action and the page's URL, and it uses not the action/page URL itself, but (see _getPasswordOrigin) the scheme+host+port combination.
If they're actually entering data into http just to be redirected to https after login, isn't that a bad scenario? You're already sending the most sensitive piece of data unencrypted across the wire.
I believe a better solution would be to redirect them to the https site and do login there...is there something I'm missing with your setup? Do they login again on the secure site?
AFAIK domain name (complete) is the current basis for remembering login. It wasn't always so, though. I'm not sure about protocol or port number, but a.domain.com is different from b.domain.com and domain.com, but same as a.domain.com/somewhere.