I have a url shortener that I created to track incoming links. Currently the php sets a cookie and inserts visitor information into the database. It attaches an id to the redirect url and redirects the user to the website.
The website has javascript on the page that takes the id and tries to set a cookie on the front end. If cookies are disabled, the javascript attempts other things to store that id. The reason I am setting the id is due to the javascript sending random pieces of information to the backend.
Is there a way for php to have a fallback if the person doesn't have cookies enabled? I don't want to create a new database entry for someone who visits the same link multiple times who doesn't have cookies enabled. Don't want to be tracking the same person as 2 or more people.
Edit
If I can't prompt the user that their cookies are disabled, are there any alternatives?
2nd Edit
One of the comments brought this up, so I thought I'd post the link here: User recognition without cookies or local storage
Related
I am working in magento. I am redirecting to another website by button click. As magento uses its own session and checks for site id or something so that not to share session data with some other site. So, if i want to share data from a site that maintains its session like that, what can be the suitable way for that?
You'd have to incorporate the session id (or the data itself) into the url (kinda unsafe) or to make a cookie that is valid over multiple domains. You can lower the risk of session hijacking by encoding the session id and checking the requesters ip, still a small risk remains when using non-ssl connections.
I am trying to write a php page that will load several different websites in different iframes. Several of those sites will need the user to login. What I need to do is basically allow the user to only type in the username and password once and then populate all the other forms (that are basically using the same user-pass pair for logging in)
Now i know that since those are external sites you don't have access to the DOM and XSS is not allowed and all, but i was wondering if theres actually any other way to achieve that.
Somebody actually suggested me to simulate keypresses and have a javascript that will basically go from field to field and essentially type in the username and pass but after doing some research I dont think thats possible since you can only simulate the event and not the actual keypress so...any other suggestions?
NOTE: I have also checked this but agreeing with the other sites/domains is not an option in my case!
Thanks -- Mike
that depends.
if those sites share a domain (the parent window and iframes), then it's possible for the top window to communicate with the child iframes. AJAX prevents cross domain (that includes inter subdomains) but iframes can communicate as long as they belong to the same top domain.
see https://stackoverflow.com/a/9338955/575527 and https://stackoverflow.com/a/9676156/575527
a better approach is to have a "top domain cookie" where that cookie is visible in all those iframes (assuming they are of the same top domain). login once using a single login page, then subsequent requests in the pages will need to check the cookie vs the session if that user is logged in.
or if those pages have different domains but access the same database, then one can just then pass the session id as a url parameter to the iframes rather than as cookies. then the website in the iframes will parse the session id and check in the database if those sessions are valid, are current, and are logged in.
all of which need additional CSRF and XSS checking as session IDs are in the open.
You cannot do what you describe in JavaScript.
However, depending on what you need to do with the data/websites once the user is logged in, you may be able to use a remote POST to simulate that behavior. See this question for more info.
Is it possible to have the same session be active across multiple open windows in a php app?
I want to have SOME of the convenience of the dreaded "remember me" checkbox type system without the same amount of risk to the user's data.
The specific use case I have run into is this: When a user receives a "friend request", an e-mail is sent to them with a link that contains a random hash and their username in the url. Say the person is already logged in to my service in one window and is checking their mail for the confirmation e-mail in another. They click the link in the confirmation e-mail and it launches a third window which initiates a GET request to the relevant confirmation page. I'd like to make it so that if the user is already logged in to the service in another window and the hash and username match those stored in the "requests" table of my database, clicking the link instantly confirms the friend. However, if they are not already logged in in another window, they are then forced to log in to confirm the friend request.
Currently if a person is logged in in another window, clicking the link launches a third window and the person must log in again regardless of whether they have another open session.
Is this functionality possible without using cookies to maintain a persistent login?
Update: This question demonstrates my own lack of understanding regarding how sessions work. The user's session IS normally preserved across concurrently open browser windows by default. The issue, as was addressed in the answer I accepted was that I had one window open with www.example.com as the URL and one with example.com as the URL, in which case a different session is created in the second window rather than continuing the session started in the first window.
If you use cookie-based sessions, the session is already maintained between windows (of the same browser executable).
The session ID is the only client-side stored token in this case, and browsers don't generally segregate cookies between different windows.
You may have an issue in that they're visiting your web site via two different domain names (www.example.com vs example.com vs www.example.org, or the like), but fundamentally there is no problem unless you try to use GET-passed session IDs.
You will technically "use cookies" - but the cookies only hold the session ID, not the session contents. If that is anathema to you, you could store the session ID using the HTML5 LocalData API, or with a Flash object, or a Java applet, or whatever...
I strongly advise against attempting to identify the clients a posteriori via their IP address or browser characteristics. Just have them store a token, and use that to determine who they are.
A typical login system has sessions and cookies . Cookies are only set if the users wants to be remembered to avoid input hes data again from that spesific browser and nothing else.
Session live while you are loggen but the will be destroyde after you close the window thus prompting for a login again.
While saving cookies to a users browser it is vital that you encrypte their data .also instead of the password save a cookie with a refrensnumber (ID) and not their password.
I am just starting to learn about web development and something has been niggling me for a while now, How a website controls what you can access and cannot access.
For example, a website like Facebook. When i first go to the site, it presents a login form, once i am logged the same page that i tried to access before now shows information relevant to me that i could only access once logged in, i can navigate to a different site and then comeback to google and it still allows me to use if without logging on again.
How exactly would a site block someone trying to access a particular page when they are not logged in, lets say the page viewProfile.php. How does the website know who to allow access to this page?
I realise this question may seem confusing and elementary but its just a something that came to me whilst viewing facebook.
Thanks.
This is a very simple concept called sessions.
When you visit facebook, it reads unique information sent to it via the connection such as IP address, browser, and some other minor information, when this information is combined it creates a unique identifier.
this unique identifier is then stored in a file like so:
d131dd02c5e6eec4693d9a0698aff95c.session
So when you login with your credentials there application add's information into this file such as last activity etc.
When you go away and come back, facebook will then read the information that's sent with every requests, it then add's it all together and creates a unique hash, if this hash exists within it's storage system it will open it up and read the contents, and know exactly who you are.
all this is combined with cookies, the unique hash is sent back to the browser and stored in your cookies folder, this cookie file is sent back to facebook with every request.
PHP Handles this for you internally so it's pretty basic to get it up and running: http://php.net/manual/en/features.sessions.php
Here's an example that may help you understand the concept a little more.
<?php
/*
* The session_start generates that hash and send a cookie to the browser
* This has to be first as you can only send cookie information before any content
*/
session_start();
/*
* Anything storeg within $_SESSION is what's been read from the session file and
* We check to see if the information has already been set on the first time the user
* visited the site
*/
if(!isset($_SESSION['hits']))
{
$_SESSION['hits'] = 0;
}
/*
* Now we increment the value every time the page is laoded
*/
$_SESSION['hits']++;
/*
* now we display the amount's of hits the user has loaded the page.
*/
echo 'You have vistited this site <strong>' . $_SESSION['hits'] . '</strong> times.';
?>
if you load this page and then hit F5, the session value get's incremented every request so you should see something like:
You have vistited this site 1 times.
You have vistited this site 2 times.
You have vistited this site 3 times.
You have vistited this site 4 times.
...
The session file is unique to each person visiting, thus meaning that when using the session variable in PHP it would be to that user only, so everyone get's there own individual session.
as your researching it's goods to search StackOverflow for certain tags, such as PHP and sessions.
https://stackoverflow.com/questions/tagged/php+session
Here's a good question in regards to cookies and sessions advantages etc.
Purpose Of PHP Sessions and Cookies and Their Differences
A website uses something called a "cookie" to store information on your computer.
This information can hold any text string, but in this case it is probably a unique ID that Facebook knows (probably stored in a database somewhere) is tied to a certain user. Cookies can only be read by the website that sent them and by the browser itself.
The login page sends a POST/GET request to a script that generally checks the username/password combo against data in a database a database. If the data is found to be valid, then the user is granted access to the websites landing page (the page after login) and a cookie is stored. If it is not, they are sent back with a error message.
Cookies can also have a "lifespan". This lifespan can be anything: for a certain amount of seconds; until you leave the site; until you close your browser; or forever (there are probably more.)
The website that sent a cookie can also delete a cookie before it expires. This is how most "logout" buttons work.
To allow only logged in users to view content you can first check for a sign that they are logged in, such as look for an active session and that it has a flag which tells you they're logged in ( which you control ). In PHP at the top of a page you can simply:
<?php session_start();
if(!isset($_SESSION['loggedin'])){
header('Location: http://example.com/login.php');
}
?>
which will redirect non logged in users to a login page. Upon success login, you should set $_SESSION['loggedin'] to a value.
To check whether a person who is logged in is allowed view a particular profile is down to looking up where the page is restricted to friends only, and if so, checking that the loggedin user's id is in the profile owner's friend field in the DB.
It is done with cookies. When you log in, the site puts a cookie into your browser for a set amount of time (generally a very long time so that you can stayed logged in). When you access the site again, your browser sends the cookie back to the site (and the site sets a fresh cookie). In any browser, you can find the list of cookies somewhere in the options.
If you want to know more about cookies, you can read the wikipedia: http://en.wikipedia.org/wiki/HTTP_cookie
Do a Google search for "Session Management."
Summary
when you login to a site you get a unique id. That id pulls your data from the database and then populates a dynamic page, like viewProfile.php with your data. So each user pulls the same file, viewProfile.php, but gets different results based on their unique id.
I have created a mobile version of a site. It uses the CodeIgniter session to store some data. This seemed okay on Blackberry a few weeks ago but now it is making multiple sessions on every page and therefore it can't access the session where the data is saved. This works fine on the desktop and iPhone. The cookies are being saved to the Blackberry. I've got it so that it using the database to save the data.
On every page it checks to see whether the phone is touch screen to show the page differently. There is also some other data. It's all being saved but into many sessions.
It's on a subdomain - m.domain.com so I'm wondering if the domain name for the cookie might need to be set differently.
EDIT:
I managed to sort it out by saving the session id in a different cookie and then calling that in a query to get the info. Thank you to the person who replied.
do you proceed you session-id on every link and every form? if not, and the client doesn't accept cookies the session will be lost on every new page load - exactly what you're describing.
EDIT: to correct that, take a look at the documentation (+ Passing the Session ID) - just add the SID-constant to all you links and forms, it will automatically be empty if the browser accepts cookies, so the url isn't that ugly for those clients.