Question for the group
The authentication system for the site Im working on seems to function
properly and all is good. A session keeps track of everything and a
cookie is used to accept or deny access... sounds as it should be I hope.
Then when all is done logging out destroys everything and the pages are
no longer accessable. Good so far.
But two things come to mind: one is preventing multiple logins of the
user/password. The solution from what Ive read seems to be using another
variable to check whether or not the user is already logged in (a simple
yes or no). Simple enough. I imagine logging out normally and deleting
all values removes this and then the cookie is deleted. But, what if the
browser is simply closed? If I understand how everything works the cookie
will still be there for a set period until its removed automatically.
What if the user logs in, closes the browser, and tries to log in again?
Is the value saying the login already exists still there? Or am I
thinking I need a solution to a problem that is already transparently
handled?
thx
(note: I sent an email about this earlier today, but I dont see it so Im
sending it again)
22  2840 
In article <Xn************************@216.168.3.44>, Theo wrote: Question for the group
The authentication system for the site Im working on seems to function
properly and all is good. A session keeps track of everything and a
cookie is used to accept or deny access... sounds as it should be I hope.
Then when all is done logging out destroys everything and the pages are
no longer accessable. Good so far.
But two things come to mind: one is preventing multiple logins of the
user/password. The solution from what Ive read seems to be using another
variable to check whether or not the user is already logged in (a simple
yes or no). Simple enough. I imagine logging out normally and deleting
all values removes this and then the cookie is deleted. But, what if the
browser is simply closed? If I understand how everything works the cookie
will still be there for a set period until its removed automatically.
What if the user logs in, closes the browser, and tries to log in again?
Is the value saying the login already exists still there? Or am I
thinking I need a solution to a problem that is already transparently
handled?
Instead of yes/no store the timestamp. And save that timestamp in the
session.
Everytime a user requests as page, compare the session timestamp with
the timestamp in the database.
If a new login has been done, the timestamp will be different.
--
Tim Van Wassenhove <http://www.timvw.info>
On Fri, 24 Sep 2004 22:45:53 -0000, Theo <in*****@noemail.com> wrote: Question for the group
The authentication system for the site Im working on seems to function
properly and all is good. A session keeps track of everything and a
cookie is used to accept or deny access... sounds as it should be I hope.
Then when all is done logging out destroys everything and the pages are
no longer accessable. Good so far.
But two things come to mind: one is preventing multiple logins of the
user/password. The solution from what Ive read seems to be using another
variable to check whether or not the user is already logged in (a simple
yes or no). Simple enough. I imagine logging out normally and deleting
all values removes this and then the cookie is deleted. But, what if the
browser is simply closed? If I understand how everything works the cookie
will still be there for a set period until its removed automatically.
What if the user logs in, closes the browser, and tries to log in again?
Is the value saying the login already exists still there? Or am I
thinking I need a solution to a problem that is already transparently
handled?
thx
(note: I sent an email about this earlier today, but I dont see it so Im
sending it again)
Right.. so are you using _SESSIONs or _COOKIEs? (or both?)
By default, both have "the same" lifespan.. for the duration of the
session. When the user closes the browser, the _SESSION or _COOKIE data
is removed (presuming you're not using cookies and setting a specified
expiration date) thus I believe you're looking for an answer to an
irrelevant question as when the user closes the browser, _all_ session
data will be destroyed, including the 'i_am_logged_in' value.. whatever
you use to distinguish =)
HTH.
Regards,
Ian
--
Ian.H
digiServ Network
London, UK http://digiserv.net/
>The authentication system for the site Im working on seems to function properly and all is good. A session keeps track of everything and a
cookie is used to accept or deny access... sounds as it should be I hope.
Then when all is done logging out destroys everything and the pages are
no longer accessable. Good so far.
But two things come to mind: one is preventing multiple logins of the
user/password.
Why? What problem are you trying to solve here?
If the intent is to prevent the sharing of pay site logins, you're
trading one problem for another (denial of access by the legitimate
user). Of course, the site operator might like this problem, as
it costs less in bandwidth. But he might lose customers and his
site might get a bad reputation.
If the intent is some kind of security for abandoned sessions or
computers left unattended, put a timestamp in the session. Update
the timestamp to the current time on each successful page load (this
part comes after the logged-in check). On each page, the logged-in
check should include checking that the timestamp is not "too old"
(whatever value you decide for that). If it is (or the login is
otherwise invalid, say, the membership expired), destroy the session
and redirect to the login page. This should take care of "abandoned
sessions": any sessions older than the timeout aren't any good any
more and they get destroyed if anyone attempts to use them. You
should also have an occasional cleanup process that deletes old
sessions which nobody attempted to use after they were abandoned
(mostly to reclaim disk space). Oh, yes, DON'T count on browsers
to delete a cookie at the appropriate time. Some desktops have
clocks that, well, suck, and may be years off. Also, sniffed cookies
may be resurrected on another computer somewhere, with a tricked-up
browser that doesn't behave like you expect.
Your definition of "too old" should take into account what users
are doing with the pages: if it takes an average user 15 minutes
to fill in ONE form or compose message text, chances are a timeout
of 20 minutes is too short.
If the intent is some kind of assumption that if there are duplicate
logins, one MUST be an unauthorized cracker or will screw up your
application, well, that assumption is often false. It's not that
uncommon for me to have several browsers running on several computers
viewing the same site all on the same monitor. Your application
should distinguish carefully between per-USER data and per-SESSION
data (for example, each session has its own shopping cart, but the
paid-until date is shared by all sessions for the same user, and
the download limit is probably per-user, not per-session).
Incidentally, I think for many applications, if you must prevent
duplicate logins, on detection of a duplicate, allow the current
login and log out ALL THE OTHERS using the same username. (I'm not
real sure how to do this in a bulletproof way, but if you use session
handlers to put the session data in a database rather than the
default temporary files, finding other sessions with the same
username becomes easier. They'd go back to the login page on the
next attempt to load a page.) This prevents legitimate users from
having a number of problems including having their system crash/reboot
and then not being able to get back in until after an annoyingly
long timeout.
The solution from what Ive read seems to be using another
variable to check whether or not the user is already logged in (a simple
yes or no). Simple enough. I imagine logging out normally and deleting
all values removes this and then the cookie is deleted. But, what if the
browser is simply closed?
If there is another session with the same username AND the timestamp
is not stale, you have a duplicate login. Act accordingly. It
MIGHT be caused by a recently-closed browser. The situation will
correct itself after the timeout period.
If there is another session with the same username and the timestamp
is stale, this might be a case of just closing the browser. You ought
to ignore records with stale timestamps (as though they don't exist),
as they can't be used any more.
If I understand how everything works the cookie
will still be there for a set period until its removed automatically.
What if the user logs in, closes the browser, and tries to log in again?
Is the value saying the login already exists still there? Or am I
Most likely, YES, and the user will be locked out. If you are
using timestamps, the lockout will only be for the timeout period.
thinking I need a solution to a problem that is already transparently
handled?
Gordon L. Burditt
Ian.H <ia*@WINDOZEdigiserv.net> wrote in
news:v7********************************@4ax.com: Right.. so are you using _SESSIONs or _COOKIEs? (or both?)
By default, both have "the same" lifespan.. for the duration of the
session. When the user closes the browser, the _SESSION or _COOKIE
data is removed (presuming you're not using cookies and setting a
specified expiration date) thus I believe you're looking for an answer
to an irrelevant question as when the user closes the browser, _all_
session data will be destroyed, including the 'i_am_logged_in' value..
whatever you use to distinguish =)
HTH.
Regards,
Ian
Session cookies (as opposed to cookies on the users computer). Yes the
cookie does have an expiration date, so it will no longer work if the
computer is left unattended for a set time, say an hour. Several of the
authentication examples I read sets the time... then sets the time limit
to a negative amount (or before the current time) on logout so it will be
deleted when the session is ended. If I read the other post correctly,
perhaps the thing to do is store the last time any protected page was
accessed, get the time of next access, and if the difference is more than
1 hour, delete the current session and redirect to the login page?
Theo <in*****@noemail.com> wrote in message news:<Xn************************@216.168.3.44>... Question for the group
The authentication system for the site Im working on seems to function
properly and all is good. A session keeps track of everything and a
cookie is used to accept or deny access... sounds as it should be I hope.
Then when all is done logging out destroys everything and the pages are
no longer accessable. Good so far.
But two things come to mind: one is preventing multiple logins of the
user/password. The solution from what Ive read seems to be using another
variable to check whether or not the user is already logged in (a simple
yes or no). Simple enough. I imagine logging out normally and deleting
all values removes this and then the cookie is deleted. But, what if the
browser is simply closed? If I understand how everything works the cookie
will still be there for a set period until its removed automatically.
What if the user logs in, closes the browser, and tries to log in again?
Is the value saying the login already exists still there? Or am I
thinking I need a solution to a problem that is already transparently
handled?
1. <http://martin.f2o.org/php/login>
2. Session _may_ also use cookies (just to store the session id)
3. If you want to avoid multiple logins, just store the session id in
user table (when he logins) and see (on every pages) if the user's
current session id is the one which is stored in DB when logins.
Storing IP may also sometimes work, but if the user is behind proxy,
it will create problem.
4. No need to check timestamp as session will expire after the
specified time in INI settings.
--
| Just another PHP saint |
Email: rrjanbiah-at-Y!com
In article <Xn*************************@216.168.3.44>, Theo wrote: If I read the other post correctly,
perhaps the thing to do is store the last time any protected page was
accessed, get the time of next access, and if the difference is more than
1 hour, delete the current session and redirect to the login page?
If you're referring to mine, you've misunderstood ;)
user logs in -> store current time in session and in database.
user requests page -> compare session and database time.
If the user logs in a second time, the time in the database will change.
So the first session time != database time.
This way:
They can always log in. (Don't have to wait for expiration time)
Only the last session will be valid.
--
Tim Van Wassenhove <http://www.timvw.info>
Tim Van Wassenhove <eu**@pi.be> wrote in
news:2r*************@uni-berlin.de: In article <Xn*************************@216.168.3.44>, Theo wrote: If I read the other post correctly,
perhaps the thing to do is store the last time any protected page was
accessed, get the time of next access, and if the difference is more
than 1 hour, delete the current session and redirect to the login
page?
If you're referring to mine, you've misunderstood ;)
user logs in -> store current time in session and in database.
user requests page -> compare session and database time.
If the user logs in a second time, the time in the database will
change. So the first session time != database time.
This way:
They can always log in. (Don't have to wait for expiration time)
Only the last session will be valid.
wouldnt be the first time I dont get something right off the bat. But it
sounds like in the above that login #2 would override #1, whether or not
#1 is still active.
In article <Xn***********************@216.168.3.44>, Theo wrote: Tim Van Wassenhove <eu**@pi.be> wrote in
news:2r*************@uni-berlin.de:
In article <Xn*************************@216.168.3.44>, Theo wrote: If I read the other post correctly,
perhaps the thing to do is store the last time any protected page was
accessed, get the time of next access, and if the difference is more
than 1 hour, delete the current session and redirect to the login
page?
If you're referring to mine, you've misunderstood ;)
user logs in -> store current time in session and in database.
user requests page -> compare session and database time.
If the user logs in a second time, the time in the database will
change. So the first session time != database time.
This way:
They can always log in. (Don't have to wait for expiration time)
Only the last session will be valid.
wouldnt be the first time I dont get something right off the bat. But it
sounds like in the above that login #2 would override #1, whether or not
#1 is still active.
Yes, that is the concept of one login per account, no? :)
--
Tim Van Wassenhove <http://www.timvw.info>
"Theo" <in*****@noemail.com> wrote in message
news:Xn************************@216.168.3.44... Question for the group
The authentication system for the site Im working on seems to function
properly and all is good. A session keeps track of everything and a
cookie is used to accept or deny access... sounds as it should be I hope.
Then when all is done logging out destroys everything and the pages are
no longer accessable. Good so far.
But two things come to mind: one is preventing multiple logins of the
user/password. The solution from what Ive read seems to be using another
variable to check whether or not the user is already logged in (a simple
yes or no). Simple enough. I imagine logging out normally and deleting
all values removes this and then the cookie is deleted. But, what if the
browser is simply closed?
If the browser is closed then nothing is sent to the web server to say so,
so any session data you have on the server will just hang around until
something happens. This can be one of the following:
(a) Another request appears which references that session_id.
(b) Expired session data is deleted by PHP.
If I understand how everything works the cookie
will still be there for a set period until its removed automatically.
By default the cookie which stores the session name and session id is a
temporary cookie. This means that it resides in memory only for the duration
of that browser session. If the user closes his browser, opens it again and
access your site there will be no session cookie for that new browser
session, so PHP will create a new session.
OTOH if the user logs in then opens up a new browser window and logs in
again then both browser instances will share the same session cookie
therefore the same session data. Even if the second login were to generate a
new session id this would be written out to the session cookie and therefore
picked up by the first login.
--
Tony Marston
http://www.tonymarston.net
What if the user logs in, closes the browser, and tries to log in again?
Is the value saying the login already exists still there? Or am I
thinking I need a solution to a problem that is already transparently
handled?
thx
(note: I sent an email about this earlier today, but I dont see it so Im
sending it again)
R. Rajesh Jeba Anbiah wrote: Theo <in*****@noemail.com> wrote in message
news:<Xn************************@216.168.3.44>... Question for the group
Storing IP may also sometimes work, but if the user is behind proxy,
it will create problem.
Will it, I think not necessarily. I agree one must not rule out multiple IP
logins per IP, but the combination username/pwd & IP can still be set to one
max, but different logins from one Ip isn't a reason in itself to close a
session or am I missing something ? (Hope not, I am gambling on this to
work!)
Pjotr Wedersteers <x3****@westerterp.com> wrote: Will it, I think not necessarily. I agree one must not rule out multiple IP
logins per IP, but the combination username/pwd & IP can still be set to one
max
Loadbalancing proxies! I ipersonally would never do anything with
the users ipaddress.
--
Daniel Tryba
Tim Van Wassenhove <eu**@pi.be> wrote in
news:2r*************@uni-berlin.de: wouldnt be the first time I dont get something right off the bat. But
it sounds like in the above that login #2 would override #1, whether
or not #1 is still active.
Yes, that is the concept of one login per account, no? :)
What if #1 shouldnt be overridden because the person is actually using
it... and #2 is someone else using the same logon?
In article <Xn*************************@216.168.3.44>, Theo wrote: Tim Van Wassenhove <eu**@pi.be> wrote in
news:2r*************@uni-berlin.de:
wouldnt be the first time I dont get something right off the bat. But
it sounds like in the above that login #2 would override #1, whether
or not #1 is still active.
Yes, that is the concept of one login per account, no? :)
What if #1 shouldnt be overridden because the person is actually using
it... and #2 is someone else using the same logon?
Then you should only verify if their credetials are correct.
And do nothing more.
--
Tim Van Wassenhove <http://www.timvw.info>
Tim Van Wassenhove <eu**@pi.be> wrote in
news:2r*************@uni-berlin.de: In article <Xn*************************@216.168.3.44>, Theo wrote: Tim Van Wassenhove <eu**@pi.be> wrote in
news:2r*************@uni-berlin.de:
wouldnt be the first time I dont get something right off the bat.
But it sounds like in the above that login #2 would override #1,
whether or not #1 is still active.
Yes, that is the concept of one login per account, no? :)
What if #1 shouldnt be overridden because the person is actually
using it... and #2 is someone else using the same logon?
Then you should only verify if their credetials are correct.
And do nothing more.
I know Im thinking worst case scenario. Really I dont expect this to
happen or and simply using a logon setting with a timestamp for old
logins will work good enough. I guess Im being paranoid ;o)
"Tony Marston" <to**@NOSPAM.demon.co.uk> wrote in
news:cj******************@news.demon.co.uk: OTOH if the user logs in then opens up a new browser window and logs
in again then both browser instances will share the same session
cookie therefore the same session data. Even if the second login were
to generate a new session id this would be written out to the session
cookie and therefore picked up by the first login.
I tested out some 'real' sites by logging in twice using different browsers
(IE and Firefox) at the same time, and both worked, allowing access to
everything. Did the same thing on my local one - there are two sessions, as
expected. I guess maybe multiple logins are not that big of a concern in
the grand scheme of things even for large sites.
Then again maybe they checked to see if the two logins were coming two
different IPs, and since they were not, didnt prevent anything.
> 3. If you want to avoid multiple logins, just store the session id in user table (when he logins) and see (on every pages) if the user's
current session id is the one which is stored in DB when logins.
Storing IP may also sometimes work, but if the user is behind proxy,
it will create problem.
Instead of that, I would destroy the previous session when the user login
in, using the session id stored in the database to locate the session file.
This way, when the user shutdowns the browser without logging out properly,
he wouldn't be prevented from logging in again.
Don't think there's any bulletproof way to stop people from sharing the same
session id. That's more a theoretical problem though.
"Chung Leong" <ch***********@hotmail.com> wrote in
news:zq********************@comcast.com: 3. If you want to avoid multiple logins, just store the session id in
user table (when he logins) and see (on every pages) if the user's
current session id is the one which is stored in DB when logins.
Storing IP may also sometimes work, but if the user is behind proxy,
it will create problem.
Instead of that, I would destroy the previous session when the user
login in, using the session id stored in the database to locate the
session file. This way, when the user shutdowns the browser without
logging out properly, he wouldn't be prevented from logging in again.
Don't think there's any bulletproof way to stop people from sharing
the same session id. That's more a theoretical problem though.
True. I suppose it I wanted to be really security minded I could force
password renewal every 30 days. Either that or have a set of 10 semi-
personal questions, 1 of which must be answered in addition to the usual
uid/pwd. Now this is getting really too much. Its not like Im making
something for the DoD ;o)
"Theo" <in*****@noemail.com> wrote in message
news:Xn*************************@216.168.3.44... "Tony Marston" <to**@NOSPAM.demon.co.uk> wrote in
news:cj******************@news.demon.co.uk:
OTOH if the user logs in then opens up a new browser window and logs
in again then both browser instances will share the same session
cookie therefore the same session data. Even if the second login were
to generate a new session id this would be written out to the session
cookie and therefore picked up by the first login.
I tested out some 'real' sites by logging in twice using different
browsers
(IE and Firefox) at the same time, and both worked, allowing access to
everything.
The fact that they allowed multiple logins using the same username does not
mean that they are using separate session ids. If they share the same
session id then they are sharing the same session data, so what you do in
one window will be available in another.
Did the same thing on my local one - there are two sessions, as
expected. I guess maybe multiple logins are not that big of a concern in
the grand scheme of things even for large sites.
Then again maybe they checked to see if the two logins were coming two
different IPs, and since they were not, didnt prevent anything.
I know for a fact that if you open up multiple browser windows using IE they
will all share the same session cookie, therefore they will share the same
session name and, by association, the same session id.
Different browsers on the same PC may not share the same session cookie, in
which case they would not be sharing the same session id.
--
Tony Marston http://www.tonymarston.net
"Tony Marston" <to**@NOSPAM.demon.co.uk> wrote in
news:cj*******************@news.demon.co.uk: I know for a fact that if you open up multiple browser windows using
IE they will all share the same session cookie, therefore they will
share the same session name and, by association, the same session id.
Different browsers on the same PC may not share the same session
cookie, in which case they would not be sharing the same session id.
Yes. This is what I did, as I figured another window in the same browser
wouldnt mean anything.
Tony Marston <to**@NOSPAM.demon.co.uk> wrote: I know for a fact that if you open up multiple browser windows using IE they
will all share the same session cookie, therefore they will share the same
session name and, by association, the same session id.
Different browsers on the same PC may not share the same session cookie, in
which case they would not be sharing the same session id.
Depends on the way you use to open the other browser windows:
Session cookies are shared between the windows of a single IE process, so
if you open a new window using File > New > Window, the new window can
access the session cookie. But if you open a new "window" using Start > Run iexplore.exe, this IE is unable to access the session cookie of the other
window.
--
Simon Stienen <http://dangerouscat.net> <http://slashlife.de>
»What you do in this world is a matter of no consequence,
The question is, what can you make people believe that you have done.«
-- Sherlock Holmes in "A Study in Scarlet" by Sir Arthur Conan Doyle
"Theo" <in*****@noemail.com> wrote in message
news:Xn*************************@216.168.3.44... "Tony Marston" <to**@NOSPAM.demon.co.uk> wrote in
news:cj*******************@news.demon.co.uk:
I know for a fact that if you open up multiple browser windows using
IE they will all share the same session cookie, therefore they will
share the same session name and, by association, the same session id.
Different browsers on the same PC may not share the same session
cookie, in which case they would not be sharing the same session id.
Yes. This is what I did, as I figured another window in the same browser
wouldnt mean anything.
Most users do not have multiple browsers on their system, so this situation
is unlikely to occur.
Some users like to have multiple windows open at the same time, so this
situation is more likely to occur. Some users like to visit the same site in
different browser windows which can cause problems depending on the
behaviour of the browser, which is totally outside of your control.
If the different browser windows share the same session cookie then they
will all share the same session name and session id, which could cause a
problem.
If the browser creates a new window without reusing the existing session
cookie then the new window will have its own session name and session id.
With Internet Explorer for example a new window may or may not share the
same session cookie depending on how it was created:
- by File->New->Window it will share the same session cookie
- by Start->Run->Iexplore.exe it will use its own session cookie, therefore
a different session.
Other browsers, such as Firefox or Opera, may have different behaviour.
On the server side it is impossible to tell if the same session id is being
shared by multiple browser windows, so they will all be treated as if they
are the same session.
If you want to restrict each user to a single login then you have to bear
all this in mind.
--
Tony Marston http://www.tonymarston.net
"Tony Marston" <to**@NOSPAM.demon.co.uk> wrote in
news:cj*******************@news.demon.co.uk:
"Theo" <in*****@noemail.com> wrote in message
news:Xn*************************@216.168.3.44... "Tony Marston" <to**@NOSPAM.demon.co.uk> wrote in
news:cj*******************@news.demon.co.uk:
I know for a fact that if you open up multiple browser windows using
IE they will all share the same session cookie, therefore they will
share the same session name and, by association, the same session
id.
Different browsers on the same PC may not share the same session
cookie, in which case they would not be sharing the same session id.
Yes. This is what I did, as I figured another window in the same
browser wouldnt mean anything.
Most users do not have multiple browsers on their system, so this
situation is unlikely to occur.
Some users like to have multiple windows open at the same time, so
this situation is more likely to occur. Some users like to visit the
same site in different browser windows which can cause problems
depending on the behaviour of the browser, which is totally outside of
your control.
If the different browser windows share the same session cookie then
they will all share the same session name and session id, which could
cause a problem.
If the browser creates a new window without reusing the existing
session cookie then the new window will have its own session name and
session id.
With Internet Explorer for example a new window may or may not share
the same session cookie depending on how it was created:
- by File->New->Window it will share the same session cookie
- by Start->Run->Iexplore.exe it will use its own session cookie,
therefore a different session.
Other browsers, such as Firefox or Opera, may have different
behaviour.
On the server side it is impossible to tell if the same session id is
being shared by multiple browser windows, so they will all be treated
as if they are the same session.
If you want to restrict each user to a single login then you have to
bear all this in mind.
Thank You
I think the best way to know is to do alot of trial and error. I am just
about to that stage. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Chewy509 |
last post by:
Hi Everyone,
I'll just start, and say I am not a PHP developer (I'm a sysadmin, who
has gotten lumped with a non-working website). But since I like to do
this type of stuff, I though I might...
|
by: jing_li |
last post by:
Hi, you all,
I am a newbee for php and I need your help. One of my coworker and I
are both developing a webpage for our project using php. We have a
copy of the same files in different location...
|
by: Steve |
last post by:
Hi,
I need to be able to open another browser from within an already opened
browser with a completely new session (using the same session
variables). How can I do this? In essence, I want to...
|
by: Gleep |
last post by:
Hey PHP Gurus,
I have some complex scripts that work fine. I have a system where sessions are validated on every
page of my application to keep them secure. Everything runs fine when I test and...
|
by: Colin McKinnon |
last post by:
Hi all,
The title says it all - I'm doing sessions with cookies. I can divide the
data within the session easily enough but I can't see when the user creates
a new window or closes an old one.
...
|
by: Bartosz Wegrzyn |
last post by:
I need help with sessions.
I createt set of web site for nav with authorization.
first I go into main.php which looks like this:
<?php
//common functions
include_once '../login/common.php';...
|
by: |
last post by:
Its strange...I have experimenting with browser hawk by using the cookie
sniffer method. However, even If adjust the security slider level in
internet options or goto advanced in the privacy tab I...
|
by: Mark |
last post by:
Hi,
I want to run in my .Net Windows Form this statement
System.Diagnostics.Process.Start(strURLCommand)
to open the browser and navigate to the specified URL.
The URL is an ASP.Net Web...
|
by: Atli |
last post by:
Introduction:
Sessions are one of the simplest and more powerful tools in a web developers arsenal. This tool is invaluable in dynamic web page development and it is one of those things every...
|
by: CloudSolutions |
last post by:
Introduction:
For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
|
by: ryjfgjl |
last post by:
In our work, we often need to import Excel data into databases (such as MySQL, SQL Server, Oracle) for data analysis and processing. Usually, we use database tools like Navicat or the Excel import...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
| |
