22  3114 
"magic_hat60622" <ma************@yahoo.comwrote in message
news:11*********************@i3g2000cwc.googlegrou ps.com...
Hi all. I've got an app that dumps a user id into a session after
successful login. the login page is http://www.mydomain.com/login.php.
If the user visits pages on my site without the www (i.e.,
http://mydomain.com/foo.php), the session works fine and login state is
maintained.
If he visits http://www.mydomain.com/foo.php, the app drops the
logged-in state.
Any idea how to fix this? I'm running php 4.4.1 w/ linux apache.
Sessions are per domain. For www.mydomain.com there is one session, and for
mydomain.com there is another. Redirect all users from www.mydomain.com to
mydomain.com or vice versa. Make sure the domain is always the same. so that
it doesn't change on the way. That way they will always use the same
session.
--
"Ohjelmoija on organismi joka muuttaa kofeiinia koodiksi" - lpk http://outolempi.net/ahdistus/ - Satunnaisesti päivittyvä nettisarjis sp**@outolempi.net | rot13(xv***@bhgbyrzcv.arg)
In article <6a*****************@reader1.news.jippii.net>, sp**@outolempi.net says...
Sessions are per domain. For www.mydomain.com there is one session, and for
mydomain.com there is anothe
A session is supposed to be a session with a particular host.
Actually PHP uses host names for sessions if you look in PHPSESSID but it
puts the domain name in by mistake. Hence his problem.
Now that all "domains" are being registered both with AND without the
particular service name (WWW FTP etc) - IE as host names - this is going
to be a big problem for PHP if it isn't sorted real soon.
You can see historically why the bug hasn't mattered but things have
changed in the domain registration business and now it matters a great
deal.
I'm suprised it hasn't been reported more generally. I've seen reports on
ecommerce web sites about mysterious failures, I wouldn't be at all
suprised if this wasn't connected. re****@otherlips.com wrote:
In article <6a*****************@reader1.news.jippii.net>,
sp**@outolempi.net says...
>>Sessions are per domain. For www.mydomain.com there is one session, and for
mydomain.com there is anothe
A session is supposed to be a session with a particular host.
Actually PHP uses host names for sessions if you look in PHPSESSID but it
puts the domain name in by mistake. Hence his problem.
Now that all "domains" are being registered both with AND without the
particular service name (WWW FTP etc) - IE as host names - this is going
to be a big problem for PHP if it isn't sorted real soon.
You can see historically why the bug hasn't mattered but things have
changed in the domain registration business and now it matters a great
deal.
I'm suprised it hasn't been reported more generally. I've seen reports on
ecommerce web sites about mysterious failures, I wouldn't be at all
suprised if this wasn't connected.
example.com and www.example.com are, by definition, two different hosts.
The fact they resolve to the same physical server is immaterial. PHP
is 100% correct in its operation.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. js*******@attglobal.net
==================
In article <W_******************************@comcast.com>, js*******@attglobal.net says...
>
example.com and www.example.com are, by definition, two different hosts.
The fact they resolve to the same physical server is immaterial. PHP
is 100% correct in its operation.
No
example.com and www.example.com are the same host by both fact and hence
definition. It is the domain being addressed not necessarily a physical
machine I agree. However...
The fact is that using www. as a prefix to a domain in order to
address a web server on that host may not be formal syntax but it is
formal by dint of common usage. Common usage for some time has been to
address the same host in either manner. Anyone reserving a domain today
will have both assigned and resolved as the same address making them
interchangable.
It is PHP that calls this a host and then provides 2 different answers as
to what that host is called during the same connection. The fact that it
comes up with 2 different answers to the same question during the same
connection should be telling you something?
That is a bug. And as big as a bug can get.
This makes PHP very much incorrect.
This is how the internet works. PHP needs to address this.PHP cannot
generate reliable sessions for all users until such time as this is
fixed.
In the mean time how about telling him how to avoid the bug?
On 26 Oct 2006 16:54:04 -0700, "magic_hat60622" <ma************@yahoo.com>
wrote:
>Hi all. I've got an app that dumps a user id into a session after
successful login. the login page is http://www.mydomain.com/login.php.
If the user visits pages on my site without the www (i.e.,
http://mydomain.com/foo.php), the session works fine and login state is
maintained.
If he visits http://www.mydomain.com/foo.php, the app drops the
logged-in state.
Any idea how to fix this? I'm running php 4.4.1 w/ linux apache.
If you want to force the session cookie to apply to a wider scope, i.e. to
apply for the mydomain.com domain instead of just the host that issued it, then
you can use session_set_cookie_params to set the domain.
This may cause problems if you have other subdomains aside from the "www" one,
unless you really do want sessions shared across all of them.
--
Andy Hassall :: an**@andyh.co.uk :: http://www.andyh.co.uk http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool
On Fri, 27 Oct 2006 15:06:03 GMT, re****@otherlips.com wrote:
>In article <6a*****************@reader1.news.jippii.net>,
sp**@outolempi.net says...
>Sessions are per domain. For www.mydomain.com there is one session, and for
mydomain.com there is anothe
A session is supposed to be a session with a particular host.
Actually PHP uses host names for sessions if you look in PHPSESSID but it
puts the domain name in by mistake. Hence his problem.
Here's an example cookie header from PHP 4.4.4:
Set-Cookie: PHPSESSID=94c296afc759879918361534d1b89014; path=/
It doesn't set the domain; it relies on the default, correct, behaviour that
the cookie applies to the host from which it was issued.
>Now that all "domains" are being registered both with AND without the
particular service name (WWW FTP etc) - IE as host names - this is going
to be a big problem for PHP if it isn't sorted real soon.
No it isn't, and neither is this new.
What do you suggest as the solution? That all session cookies should have
their domain set to the TLD of the host issuing them? Then you end up with the
sessions leaking across domains, which is much worse.
If you want to modify the properties of the session cookie for your particular
circumstances, PHP has the session_set_cookie_params function.
--
Andy Hassall :: an**@andyh.co.uk :: http://www.andyh.co.uk http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool re****@otherlips.com wrote:
In article <W_******************************@comcast.com>,
js*******@attglobal.net says...
>>example.com and www.example.com are, by definition, two different hosts.
The fact they resolve to the same physical server is immaterial. PHP
is 100% correct in its operation.
No
example.com and www.example.com are the same host by both fact and hence
definition. It is the domain being addressed not necessarily a physical
machine I agree. However...
Actually, not. It is a common misconception. I can easily set up one
host as example.com - and it be an email server, for instance. www.example.com could be on another machine. And ftp.example.com could,
obviously, be a third machine.
Back in the 70's and early 80's before the internet became a commodity
(and was generally known as arpanet), it was quite common to have the
email server set up as example.com. And depending on the size of the
company, you could also have ftp.example.com, gopher.example.com and others.
The fact is that using www. as a prefix to a domain in order to
address a web server on that host may not be formal syntax but it is
formal by dint of common usage. Common usage for some time has been to
address the same host in either manner. Anyone reserving a domain today
will have both assigned and resolved as the same address making them
interchangable.
Common usage is not the same as the RFC's. RFC's determine what is a
host and what isn't. It is quite common to have www.example.com and
example.com point to the same host. But that does not change the fact
that they identify two different hosts - which just happens to be the
same machine.
Even Apache and IIS have to be set up to handle both www.example.com and
example.com. Setting up one does NOT set up the other.
It is PHP that calls this a host and then provides 2 different answers as
to what that host is called during the same connection. The fact that it
comes up with 2 different answers to the same question during the same
connection should be telling you something?
It is the RFC's which call this a host. PHP is following the RFC's in
its operation.
Of course, you can always put in a request to change the RFC's.
That is a bug. And as big as a bug can get.
This makes PHP very much incorrect.
This is how the internet works. PHP needs to address this.PHP cannot
generate reliable sessions for all users until such time as this is
fixed.
In the mean time how about telling him how to avoid the bug?
Yes, this is how the internet works. And PHP is working correctly.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. js*******@attglobal.net
==================
In article <ks********************************@4ax.com>, an**@andyh.co.uk
says...
What do you suggest as the solution? That all session cookies should have
their domain set to the TLD of the host issuing them? Then you end up with the
sessions leaking across domains, which is much worse.
You seem confused as to what PHP uses to track sessions. And the
difference between a host and a domain. PHP is using hosts, at least it
calls it a host in PHPSESSID, perhaps it should just use domains?
I suggest you all stop trying to disguise the massive bug in PHP
The simple fact is - If you connect to a web site PHP will generate 2
different answers to the question "what is the name of the host I am now
connected to?"
It doesnt matter how its configured or what its called - PHP should not
generate 2 sessions under any circumstances. THAT is the bug - it does -
every time the situation (which is now commonplace) occurs.
This is the reason the originator of this thread has a problem.
That is a bug. A serious bug. It isn't as mentioned by someone elsewhere
a difficult concept.
The entire and sole purpose of A session is to enable tracking of a user
during that session. PHP generates 2 sessions thereby preventing this.
PHP is broke.
You can waffle on all you like but the bug is there - its hard, its
simple to reproduce, its in every release of PHP, it causes lost data on
web sites and faults the average implementer has difficulty tracking
down, it confuses log on procedures therby reducing site security, and
its all because PHP can't determine the host name its connected to
accurately and provides 2 values for the variable "HOST" in PHPSESSID
instead of one.
Stop waffling and arrange to sort it or a very public announcement will
need to be made to secure peoples web sites.
In article <Jf******************************@comcast.com>, js*******@attglobal.net says...
Actually, not. It is a common misconception. I can easily set up one
host as example.com - and it be an email server, for instance.
www.example.com could be on another machine. And ftp.example.com could,
obviously, be a third machine.
The point is this is not how its done. re****@now.com wrote:
In article <ks********************************@4ax.com>, an**@andyh.co.uk
says...
>What do you suggest as the solution? That all session cookies should have
their domain set to the TLD of the host issuing them? Then you end up with the
sessions leaking across domains, which is much worse.
You seem confused as to what PHP uses to track sessions. And the
difference between a host and a domain. PHP is using hosts, at least it
calls it a host in PHPSESSID, perhaps it should just use domains?
I suggest you all stop trying to disguise the massive bug in PHP
The simple fact is - If you connect to a web site PHP will generate 2
different answers to the question "what is the name of the host I am now
connected to?"
It doesnt matter how its configured or what its called - PHP should not
generate 2 sessions under any circumstances. THAT is the bug - it does -
every time the situation (which is now commonplace) occurs.
WRONG, WRONG, WRONG! These are two different hosts, and require two
different sessions.
Point me to ONE SINGLE RFC which says example.com and www.example.com
are the same host. "Common usage" does not count!
And different hosts have different sessions.
This is the reason the originator of this thread has a problem.
That is a bug. A serious bug. It isn't as mentioned by someone elsewhere
a difficult concept.
It is NOT A BUG! It is how the sessions, the HTTP protocol and the
internet itself work!
The entire and sole purpose of A session is to enable tracking of a user
during that session. PHP generates 2 sessions thereby preventing this.
PHP is broke.
That is one use, yes. But there are many different uses.
You can waffle on all you like but the bug is there - its hard, its
simple to reproduce, its in every release of PHP, it causes lost data on
web sites and faults the average implementer has difficulty tracking
down, it confuses log on procedures therby reducing site security, and
its all because PHP can't determine the host name its connected to
accurately and provides 2 values for the variable "HOST" in PHPSESSID
instead of one.
Stop waffling and arrange to sort it or a very public announcement will
need to be made to secure peoples web sites.
You can complain all you want about it being a bug. But that doesn't
make it a bug. Learn how things really work. And show us exactly which
RFC is being violated by this "bug".
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. js*******@attglobal.net
==================
On Wed, 01 Nov 2006 11:58:31 GMT, re****@now.com wrote:
>In article <ks********************************@4ax.com>, an**@andyh.co.uk
says...
> What do you suggest as the solution? That all session cookies should have
their domain set to the TLD of the host issuing them? Then you end up with the
sessions leaking across domains, which is much worse.
You seem confused as to what PHP uses to track sessions. And the
difference between a host and a domain. PHP is using hosts, at least it
calls it a host in PHPSESSID
Where does it do this?
>You can waffle on all you like but the bug is there - its hard, its
simple to reproduce,
Please post a reproducable test case and submit it to http://bugs.php.net
>its all because PHP can't determine the host name its connected to
accurately and provides 2 values for the variable "HOST" in PHPSESSID
instead of one.
What does this statement mean? There are zero variables named "HOST" in
"PHPSESSID", the statement doesn't even make sense - there's nothing "in" the
PHPSESSID cookie, other than the session ID.
Cookies have a "Domain" attribute, which if left blank means it's only sent
back to the host from which it originated. If it's set, then it's used as a
tail-match on the hostname, so the cookie can apply to a domain (or subdomain)
and all lower-level subdomains.
PHP doesn't sent the domain parameter (by default, if you want this you can
change the settings), so sessions are per host, and rely on the cookie
specification's (correct) interpretation of this.
Earlier I posted an example Set-Cookie header with the output from a typical
session cookie, it doesn't have a "host" in there - it can't do, since that's
not part of the cookie specification.
Post some code or headers captured from PHP to demonstrate what you're on
about.
--
Andy Hassall :: an**@andyh.co.uk :: http://www.andyh.co.uk http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool ni*****@by.uk wrote:
In article <Jf******************************@comcast.com>,
js*******@attglobal.net says...
>>Actually, not. It is a common misconception. I can easily set up one
host as example.com - and it be an email server, for instance.
www.example.com could be on another machine. And ftp.example.com could,
obviously, be a third machine.
The point is this is not how its done.
The point is this is how the RFC's document hosts. The fact that
someone has two hosts pointing at the same machine is immaterial.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. js*******@attglobal.net
==================
>You seem confused as to what PHP uses to track sessions. And the
>difference between a host and a domain. PHP is using hosts, at least it
calls it a host in PHPSESSID, perhaps it should just use domains?
I suggest you all stop trying to disguise the massive bug in PHP
Virtualhosting in Apache is not a bug.
I also dispute that the "bug" you are describing in PHP can be fixed
in PHP. It's the browser, not the server that decides what cookies
to send to the server. If the browser thinks that it's talking to
foo.com, it won't *SEND* the session cookie to www.foo.com, which
is how PHP figures out it's in the same session. Therefore it has
no idea whether it's assigning the first or the second session
cookie.
>The simple fact is - If you connect to a web site PHP will generate 2
different answers to the question "what is the name of the host I am now
connected to?"
On some commercial hosting sites, it will generate 100 different
answers to that question, because there are 99 customer web sites
on that same server, plus the server's own name. Yes, that site
has 100 DNS entries. And maybe even 100 *reverse* DNS entries.
Those web sites are independent and they should NOT share sessions
between different web sites on the same server. That's a security
hole. It allows one web customer to attack the site of another web
customer on the same server (not that there aren't other kinds of
security issues in this setup also).
If you really want foo.com and www.foo.com to be the same web site,
use Apache to redirect any reference to one to the other one.
>It doesnt matter how its configured or what its called - PHP should not
generate 2 sessions under any circumstances.
It certainly should generate 2 sessions for accessing two different
web sites. Even if they have different IP addresses, that doesn't
mean it's not the same machine.
>THAT is the bug - it does -
every time the situation (which is now commonplace) occurs.
This is the reason the originator of this thread has a problem.
That is a bug. A serious bug. It isn't as mentioned by someone elsewhere
a difficult concept.
The entire and sole purpose of A session is to enable tracking of a user
during that session.
On one web site. Cookies are *NOT* intended to be able to track a
sequence of web accesses to arbitrary web sites, and neither are
sessions.
>PHP generates 2 sessions thereby preventing this.
PHP is broke.
>You can waffle on all you like but the bug is there - its hard, its
simple to reproduce, its in every release of PHP, it causes lost data on
web sites and faults the average implementer has difficulty tracking
down, it confuses log on procedures therby reducing site security, and
its all because PHP can't determine the host name its connected to
accurately and provides 2 values for the variable "HOST" in PHPSESSID
instead of one.
Stop waffling and arrange to sort it or a very public announcement will
need to be made to secure peoples web sites.
In article <12************@corp.supernews.com>, go***********@burditt.org
says...
I also dispute that the "bug" you are describing in PHP can be fixed
in PHP. It's the browser, not the server that decides what cookies
to send to the server.
It is PHPSESSID that is duplicated and a variable within it that is wrong
- so you tell me what generates that ?
In article <12************@corp.supernews.com>, go***********@burditt.org
says...
>
If you really want foo.com and www.foo.com to be the same web site,
use Apache to redirect any reference to one to the other one.
I dont particularly - that is just how its done in the real world.
PHP is a massive security hazard until such time as it can deal with that
whether you want to call it a bug or not.
In article <12************@corp.supernews.com>, go***********@burditt.org
says...
It certainly should generate 2 sessions for accessing two different
web sites. Even if they have different IP addresses, that doesn't
mean it's not the same machine.
Same IP address same site same connection 2 sessions - should only be 1 -
It IS the same machine.
clearly people are being particularly dense or are deliberately trying to
disguise a massive security problem by making a simple bug seem complex.
it isnt. its both clear and obvious.
Looks like I'll have to start wirting it up for magazine publication.
Shame because I'd rather have kept it inside the community.
In article <12************@corp.supernews.com>, go***********@burditt.org
says...
On one web site. Cookies are *NOT* intended to be able to track a
sequence of web accesses to arbitrary web sites, and neither are
sessions.
That is quite correct and PHP can't do it because of the bug so reported. el****@cats.com wrote:
In article <12************@corp.supernews.com>, go***********@burditt.org
says...
>>It certainly should generate 2 sessions for accessing two different
web sites. Even if they have different IP addresses, that doesn't
mean it's not the same machine.
Same IP address same site same connection 2 sessions - should only be 1 -
It IS the same machine.
clearly people are being particularly dense or are deliberately trying to
disguise a massive security problem by making a simple bug seem complex.
it isnt. its both clear and obvious.
Looks like I'll have to start wirting it up for magazine publication.
Shame because I'd rather have kept it inside the community.
Same machine - but DIFFERENT HOSTS! That's what you don't get!
For instance - shared hosting may have 150 different sites on the same
machine. Are you saying there should be one session for all 150 sites?
After all - it is the same ip address and same connection.
Ah, but you also said "same site name". Sure, if you have two different
connections to example.com, you will only have one session. And if you
have two different connections to www.example.com, you will have one
session.
But - if you have a connection to example.com and another connection to www.example.com, you will have two different sessions. It doesn't
matter if example.com and www.example.com are on the same machine or
not. They are DEFINED BY THE RFC's to be two different hosts.
If you want that to change, then you need to get a change made to the
RFC's for all of the internet.
PHP is working exactly as the RFC's define.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. js*******@attglobal.net
================== el****@cats.net wrote:
In article <12************@corp.supernews.com>, go***********@burditt.org
says...
>>I also dispute that the "bug" you are describing in PHP can be fixed
in PHP. It's the browser, not the server that decides what cookies
to send to the server.
It is PHPSESSID that is duplicated and a variable within it that is wrong
- so you tell me what generates that ?
It is generated by PHP. But it is SENT BY THE BROWSER. And it is sent
ONLY TO THE ORIGINATING DOMAIN.
No bug.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. js*******@attglobal.net
==================
>I also dispute that the "bug" you are describing in PHP can be fixed
>in PHP. It's the browser, not the server that decides what cookies
to send to the server.
It is PHPSESSID that is duplicated
The variable is duplicated because the browser DID NOT SEND the one
with the other domain on requests with *this* domain. Since PHP
did not get a session ID (there's no way to tell if that's because
there isn't one, or because there are several in several different
domains but the browser didn't send them), it made a new one, just
like it's supposed to do.
>and a variable within it that is wrong
PHPSESSID does not have variables within it. It's just a string
of characters that acts like a database key.
>- so you tell me what generates that ?
Browsers sending cookies back only to the site that sent them
when they are *supposed* to do exactly that.
>If you really want foo.com and www.foo.com to be the same web site,
>use Apache to redirect any reference to one to the other one.
I dont particularly - that is just how its done in the real world.
PHP is a massive security hazard until such time as it can deal with that
whether you want to call it a bug or not.
Please explain why this is any kind of security hazard. A site
where you have to keep logging in repeatedly because sessions in
two domains aren't the same would not seem to be a security hole:
in the extreme case where nobody can access anything, there are no
information leaks or ability for anyone to change anything.
>It certainly should generate 2 sessions for accessing two different
>web sites. Even if they have different IP addresses, that doesn't
mean it's not the same machine.
Same IP address same site same connection 2 sessions - should only be 1 -
It IS the same machine.
No, ISPs very often put many, many web sites (e.g. 100, and no,
that's not an exaggeration) on the same machine and use only a
single IP address to do it. They are *NOT* supposed to be the same
web site, and it *DOES* make a difference which host name you put
in the URL (even though they all point at the same IP). The only
problem with this is that some old browsers, like netscape 1.1,
don't send the Host: header with a HTTP request so it doesn't work,
but nobody uses those any more.
>clearly people are being particularly dense or are deliberately trying to
disguise a massive security problem by making a simple bug seem complex.
What *security* problem? If nobody can stay logged in, the system
seems pretty secure to me, almost as good as unplugging it, but still
secure.
>Looks like I'll have to start wirting it up for magazine publication.
Shame because I'd rather have kept it inside the community.
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Dave Mateer |
last post by:
Hi
Why does the following code allow me to keep the same session when in
the same sub domain (ie admin.localhost), yet not when I goto another
related domain eg main.localhost?
I would like...
|
by: Andy |
last post by:
Hi all,
I'm trying to get the hang of Sessions using this little test program
shown below. However, the first page starts up a couple of session
variables (if they have not been started...
|
by: FLEB |
last post by:
I've been trying to find a way to transfer session data (login information
and such) between different domains, both on the same shared host. I think
(I haven't tested yet, though) that using the...
|
by: Mark H |
last post by:
Hey all--
I'm building a database and I basically need to keep out people who
aren't authorized, but it's not like I need top security here. I'm just
doing basic user/pass of a SQL database, and...
|
by: Guy Hocking |
last post by:
Hi there,
I am having trouble with an ASP login that uses sessions to control access
to certain pages. However the sessions are not being carried accross upon
using response.redirect.
I realise...
|
by: strycat |
last post by:
Hello,
I've got two different sets of ASP scripts on my server. Each set is
kept in their own directory. Both sets of scripts use sessions. I
want to make sure that the sessions are not...
|
by: pek |
last post by:
OK, I've been having this problem for quite some time but never until
now I really needed a solution. I have never thought of a work around,
so I really need your help. Sorry if this has been...
|
by: Dave |
last post by:
Hopefully this is an easy question for those with more experience.
I have two separate programs that I want to use together on a website
Program A starts first and calls session_start().
...
|
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: Faith0G |
last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome former...
|
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: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
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...
| |
