Hi,
See the previous thread Request.Form abuse in this newsgroup...
I'm looking for a simple and efficient way to prevent people hijacking the
<formtags on my websites and using them to send spam. I would imagine
they're using the HttpWebRequest method for this.
Essentially, it would require a property on a WebForm that indicates whether
it is *only* for PostBack (true by default, but configurable), which would
have any client POST request which is not from the URL of the page itself
would be ignored.
Alternatively, a "global" flag which could be set in web.config.
I think this would be of great benefit to everyone, as this sort of attack
is clearly becoming more and more common.
Does anyone have any suggestions for a good way to implement this?
I'm sure, as a group, we could come up with something really solid which
would help us all - as Juan said, we're all up the creek with this.
Let's get our thinking caps on, guys...
Who knows - we might even let Microsoft use it in a future version of
ASP.NET... ;-)
Mark
12  2116 
"Mark Rae" <ma**@markNOSPAMrae.comwrote in message
news:OU**************@TK2MSFTNGP04.phx.gbl...
Hi,
See the previous thread Request.Form abuse in this newsgroup...
I'm looking for a simple and efficient way to prevent people hijacking the
<formtags on my websites and using them to send spam. I would imagine
they're using the HttpWebRequest method for this.
Essentially, it would require a property on a WebForm that indicates
whether it is *only* for PostBack (true by default, but configurable),
which would have any client POST request which is not from the URL of the
page itself would be ignored.
Alternatively, a "global" flag which could be set in web.config.
I think this would be of great benefit to everyone, as this sort of attack
is clearly becoming more and more common.
Does anyone have any suggestions for a good way to implement this?
I'm sure, as a group, we could come up with something really solid which
would help us all - as Juan said, we're all up the creek with this.
Let's get our thinking caps on, guys...
Who knows - we might even let Microsoft use it in a future version of
ASP.NET... ;-)
Mark
I'll start with a suggestion and see where the holes spring from!
A list of forms that are only subject to postback on submission is easy to
create and could reside in web.config (or anywhere cachable) - crude, but we
can think of another way later. A begin request intercepted in an
ihttpmodule could verify the ispostback property of any request. If its not
a postback form, and is in the list of forms that require postback then dump
the request and return a redirect to some random fictitious URL. It wont
even touch the actual form being requested.
--
--
Regards
John Timney (MVP)
VISIT MY WEBSITE: http://www.johntimney.com http://www.johntimney.com/blog
"John Timney (MVP)" <x_****@timney.eclipse.co.ukwrote in message
news:9c******************************@eclipse.net. uk...
John,
A list of forms that are only subject to postback on submission is easy to
create and could reside in web.config (or anywhere cachable) - crude, but
we can think of another way later. A begin request intercepted in an
ihttpmodule could verify the ispostback property of any request. If its
not a postback form, and is in the list of forms that require postback
then dump the request and return a redirect to some random fictitious URL.
It wont even touch the actual form being requested.
I like it!
If we were to use a real rather than a fictitious URL for the redirect, do
you think that would be a good thing or a bad thing? I guess it would be a
bad thing because (I suppose) it would look to the target URL that the
posting was coming from our IP address rather than the spammer's IP
address...
Being based in the UK, I think I would find it rather satisfying if the
spammers suddenly found themselves trying to post here: http://www.met.police.uk/computercrime/
:-)
I think I would redirect them to a large video file on one of the online
video places which may well crash their program with the size of the
response. That said, its not fair to send them to someone else server and
use their bandwidth, hence the suggestion of the fictitious URL.
On detecting an attempt to use a postback it would actually be quite easy to
also block their IP real time in the filter, so any future request from them
was always dropped or always resulted in a large video being sent as the
response. It would be a one hit system.
I've done most of what we're dicsussing in the past on net 1.1, but not for
this reason so the code should be very easy to put together.......I'm still
waiting for people to find holes in the suggestion though - Juans a likely
candidate for sinking my idea......lol
--
--
Regards
John Timney (MVP)
VISIT MY WEBSITE: http://www.johntimney.com http://www.johntimney.com/blog
"Mark Rae" <ma**@markNOSPAMrae.comwrote in message
news:ed**************@TK2MSFTNGP03.phx.gbl...
"John Timney (MVP)" <x_****@timney.eclipse.co.ukwrote in message
news:9c******************************@eclipse.net. uk...
John,
>A list of forms that are only subject to postback on submission is easy
to create and could reside in web.config (or anywhere cachable) - crude,
but we can think of another way later. A begin request intercepted in an
ihttpmodule could verify the ispostback property of any request. If its
not a postback form, and is in the list of forms that require postback
then dump the request and return a redirect to some random fictitious
URL. It wont even touch the actual form being requested.
I like it!
If we were to use a real rather than a fictitious URL for the redirect, do
you think that would be a good thing or a bad thing? I guess it would be a
bad thing because (I suppose) it would look to the target URL that the
posting was coming from our IP address rather than the spammer's IP
address...
Being based in the UK, I think I would find it rather satisfying if the
spammers suddenly found themselves trying to post here:
http://www.met.police.uk/computercrime/
:-)
this is what validation of viewstate is for. there is nothing you can about
people that know to do a get before the post to get required hiddenfields.
all screenscrape tools help to do this.
-- bruce (sqlwork.com)
"Mark Rae" <ma**@markNOSPAMrae.comwrote in message
news:OU**************@TK2MSFTNGP04.phx.gbl...
Hi,
See the previous thread Request.Form abuse in this newsgroup...
I'm looking for a simple and efficient way to prevent people hijacking the
<formtags on my websites and using them to send spam. I would imagine
they're using the HttpWebRequest method for this.
Essentially, it would require a property on a WebForm that indicates
whether it is *only* for PostBack (true by default, but configurable),
which would have any client POST request which is not from the URL of the
page itself would be ignored.
Alternatively, a "global" flag which could be set in web.config.
I think this would be of great benefit to everyone, as this sort of attack
is clearly becoming more and more common.
Does anyone have any suggestions for a good way to implement this?
I'm sure, as a group, we could come up with something really solid which
would help us all - as Juan said, we're all up the creek with this.
Let's get our thinking caps on, guys...
Who knows - we might even let Microsoft use it in a future version of
ASP.NET... ;-)
Mark
re:
I'm still waiting for people to find holes in the suggestion though - Juans a likely candidate for
sinking my idea......lol
<lol>
I've been mulling it over, trying to think of a failsafe method...and drawing a blank.
re:
A list of forms that are only subject to postback on submission is easy to create and could reside
in web.config (or anywhere cachable) - crude, but we can think of another way later.
That could get cumbersome.
re:
A begin request intercepted in an ihttpmodule could verify the ispostback property of any request.
Remember that the legal use of the form also involves a postback ( does it, Mark? ),
so you can't block on the basis of the request being a postback.
re:
If its not a postback form, and is in the list of forms that require postback then dump the
request and return a redirect to some random fictitious URL. It wont even touch the actual form
being requested.
If what I suspect is true, the reverse procedure would work.
As far as I can determine, the crux is that they aren't using postback, but posting directly to the
form.
( Am I right in assuming that ? ) I need a reality check ... ;-)
If that is so, we shouldn't be thinking about payback (as tempting as it is),
but about a solid defense, preferably one which is simple to implement.
So, if the request being a postback is a requirement, would checking for IsPostBack and,
if it isn't a Postback, clearing all the fields accomplish what we want ?
If the hackers/spammers are *not* using Postback (I am assuming that...) that should work.
The key is whether they *are* POSTing without having requested the page.
If not, then I need to think about this some more.
re:
On detecting an attempt to use a postback it would actually be quite easy to also block their IP
real time in the filter
Wouldn't blocking postbacks also block the intended legal use of the feedback form ?
Juan T. Llibre, asp.net MVP
asp.net faq : http://asp.net.do/faq/
foros de asp.net, en español : http://asp.net.do/foros/
===================================
"John Timney (MVP)" <x_****@timney.eclipse.co.ukwrote in message
news:cZ******************************@eclipse.net. uk...
>I think I would redirect them to a large video file on one of the online video places which may
well crash their program with the size of the response. That said, its not fair to send them to
someone else server and use their bandwidth, hence the suggestion of the fictitious URL.
On detecting an attempt to use a postback it would actually be quite easy to also block their IP
real time in the filter, so any future request from them was always dropped or always resulted in
a large video being sent as the response. It would be a one hit system.
I've done most of what we're dicsussing in the past on net 1.1, but not for this reason so the
code should be very easy to put together.......I'm still waiting for people to find holes in the
suggestion though - Juans a likely candidate for sinking my idea......lol
--
--
Regards
John Timney (MVP)
VISIT MY WEBSITE:
http://www.johntimney.com
http://www.johntimney.com/blog
"Mark Rae" <ma**@markNOSPAMrae.comwrote in message news:ed**************@TK2MSFTNGP03.phx.gbl...
>"John Timney (MVP)" <x_****@timney.eclipse.co.ukwrote in message
news:9c******************************@eclipse.net .uk...
John,
>>A list of forms that are only subject to postback on submission is easy to create and could
reside in web.config (or anywhere cachable) - crude, but we can think of another way later. A
begin request intercepted in an ihttpmodule could verify the ispostback property of any request.
If its not a postback form, and is in the list of forms that require postback then dump the
request and return a redirect to some random fictitious URL. It wont even touch the actual form
being requested.
I like it!
If we were to use a real rather than a fictitious URL for the redirect, do you think that would
be a good thing or a bad thing? I guess it would be a bad thing because (I suppose) it would look
to the target URL that the posting was coming from our IP address rather than the spammer's IP
address...
Being based in the UK, I think I would find it rather satisfying if the spammers suddenly found
themselves trying to post here: http://www.met.police.uk/computercrime/
:-)
I was thinking more along the lines of extending the Page class. I have done
several ASP.Net apps that use an extended Page class for various purposes.
One could easily add a property that handled the situation. But I'm not
saying that the configuration idea is a bad one. I honestly don't know which
would be better.
--
HTH,
Kevin Spencer
Microsoft MVP
Short Order Coder http://unclechutney.blogspot.com
What You Seek Is What You Get
"Juan T. Llibre" <no***********@nowhere.comwrote in message
news:eM**************@TK2MSFTNGP02.phx.gbl...
re:
>I'm still waiting for people to find holes in the suggestion though -
Juans a likely candidate for sinking my idea......lol
<lol>
I've been mulling it over, trying to think of a failsafe method...and
drawing a blank.
re:
>A list of forms that are only subject to postback on submission is easy
to create and could reside in web.config (or anywhere cachable) - crude,
but we can think of another way later.
That could get cumbersome.
re:
>A begin request intercepted in an ihttpmodule could verify the ispostback
property of any request.
Remember that the legal use of the form also involves a postback ( does
it, Mark? ),
so you can't block on the basis of the request being a postback.
re:
>If its not a postback form, and is in the list of forms that require
postback then dump the request and return a redirect to some random
fictitious URL. It wont even touch the actual form being requested.
If what I suspect is true, the reverse procedure would work.
As far as I can determine, the crux is that they aren't using postback,
but posting directly to the form.
( Am I right in assuming that ? ) I need a reality check ... ;-)
If that is so, we shouldn't be thinking about payback (as tempting as it
is),
but about a solid defense, preferably one which is simple to implement.
So, if the request being a postback is a requirement, would checking for
IsPostBack and,
if it isn't a Postback, clearing all the fields accomplish what we want ?
If the hackers/spammers are *not* using Postback (I am assuming that...)
that should work.
The key is whether they *are* POSTing without having requested the page.
If not, then I need to think about this some more.
re:
>On detecting an attempt to use a postback it would actually be quite easy
to also block their IP real time in the filter
Wouldn't blocking postbacks also block the intended legal use of the
feedback form ?
Juan T. Llibre, asp.net MVP
asp.net faq : http://asp.net.do/faq/
foros de asp.net, en español : http://asp.net.do/foros/
===================================
"John Timney (MVP)" <x_****@timney.eclipse.co.ukwrote in message
news:cZ******************************@eclipse.net. uk...
>>I think I would redirect them to a large video file on one of the online
video places which may well crash their program with the size of the
response. That said, its not fair to send them to someone else server and
use their bandwidth, hence the suggestion of the fictitious URL.
On detecting an attempt to use a postback it would actually be quite easy
to also block their IP real time in the filter, so any future request
from them was always dropped or always resulted in a large video being
sent as the response. It would be a one hit system.
I've done most of what we're dicsussing in the past on net 1.1, but not
for this reason so the code should be very easy to put together.......I'm
still waiting for people to find holes in the suggestion though - Juans a
likely candidate for sinking my idea......lol
--
--
Regards
John Timney (MVP)
VISIT MY WEBSITE:
http://www.johntimney.com
http://www.johntimney.com/blog
"Mark Rae" <ma**@markNOSPAMrae.comwrote in message
news:ed**************@TK2MSFTNGP03.phx.gbl...
>>"John Timney (MVP)" <x_****@timney.eclipse.co.ukwrote in message
news:9c******************************@eclipse.ne t.uk...
John,
A list of forms that are only subject to postback on submission is easy
to create and could reside in web.config (or anywhere cachable) -
crude, but we can think of another way later. A begin request
intercepted in an ihttpmodule could verify the ispostback property of
any request. If its not a postback form, and is in the list of forms
that require postback then dump the request and return a redirect to
some random fictitious URL. It wont even touch the actual form being
requested.
I like it!
If we were to use a real rather than a fictitious URL for the redirect,
do you think that would be a good thing or a bad thing? I guess it would
be a bad thing because (I suppose) it would look to the target URL that
the posting was coming from our IP address rather than the spammer's IP
address...
Being based in the UK, I think I would find it rather satisfying if the
spammers suddenly found themselves trying to post here:
http://www.met.police.uk/computercrime/
:-)
"Juan T. Llibre" <no***********@nowhere.comwrote in message
news:eM**************@TK2MSFTNGP02.phx.gbl...
I've been mulling it over, trying to think of a failsafe method...and
drawing a blank.
Yes - it's not as straightforward as it sounds...
>A list of forms that are only subject to postback on submission is easy
to create and could reside in web.config (or anywhere cachable) - crude,
but we can think of another way later.
That could get cumbersome.
I would agree.
Remember that the legal use of the form also involves a postback ( does
it, Mark? ),
In this particular case, no it doesn't - that's the weird thing! They have
chosen (at random, I'm sure) a ContentPage whose MasterPage has a <formtag
(obviously, or nothing would work) - but the ContentPage in question doesn't
actually have any data-entry controls nor any submit buttons...
so you can't block on the basis of the request being a postback.
That's right, in this case anyway...
>If its not a postback form, and is in the list of forms that require
postback then dump the request and return a redirect to some random
fictitious URL. It wont even touch the actual form being requested.
If what I suspect is true, the reverse procedure would work.
Yes.
As far as I can determine, the crux is that they aren't using postback,
but posting directly to the form. ( Am I right in assuming that ? ) I
need a reality check ... ;-)
That is correct - I suspect they're using HttpWebRequest or somesuch...
If that is so, we shouldn't be thinking about payback (as tempting as it
is),
but about a solid defense, preferably one which is simple to implement.
Indeed.
So, if the request being a postback is a requirement, would checking for
IsPostBack and,
if it isn't a Postback, clearing all the fields accomplish what we want ?
No, because there aren't any fields to clear! They are adding fields to the
page's Request.Form object dynamically...
>On detecting an attempt to use a postback it would actually be quite easy
to also block their IP real time in the filter
Wouldn't blocking postbacks also block the intended legal use of the
feedback form ?
As above, this isn't a feedback form!!! It has no textboxes or submit
buttons etc. All it has is text and hyperlinks.
"Mark Rae" <ma**@markNOSPAMrae.comwrote in message
news:%2******************@TK2MSFTNGP04.phx.gbl...
"Juan T. Llibre" <no***********@nowhere.comwrote in message
news:eM**************@TK2MSFTNGP02.phx.gbl...
>I've been mulling it over, trying to think of a failsafe method...and
drawing a blank.
Yes - it's not as straightforward as it sounds...
Has anyone made any further progress with this, because I certainly
haven't...
In fact, as Bruce hinted, I'm not sure that it's even technically
possible...
So, in the meantime, I've gone with an IP blocking solution which has killed
the spammers dead in their tracks.
If anyone's interested, the IP addresses I've caught (so far!) are:
206.83.210.59
216.224.117.178
58.65.233.129
66.79.163.226
I think a list of IP's would probably have to do, and as for blocking them
do it in the module as suggested and actually redirect them to one of the
large download sites. Stop them with some payback. I think I have this
written already on another server - might power it up and ressurect the
code, although it can only be 30 lines or so. Now if you could autoextract
the IP's by identifying they were a nusicance to your site, it would be a
useful little sytem......but I agree with Bruce also, not a lot you can do
other than blocking the IP's.
--
Regards
John Timney (MVP)
VISIT MY WEBSITE: http://www.johntimney.com http://www.johntimney.com/blog
"Mark Rae" <ma**@markNOSPAMrae.comwrote in message
news:OT****************@TK2MSFTNGP03.phx.gbl...
"Mark Rae" <ma**@markNOSPAMrae.comwrote in message
news:%2******************@TK2MSFTNGP04.phx.gbl...
>"Juan T. Llibre" <no***********@nowhere.comwrote in message
news:eM**************@TK2MSFTNGP02.phx.gbl...
>>I've been mulling it over, trying to think of a failsafe method...and
drawing a blank.
Yes - it's not as straightforward as it sounds...
Has anyone made any further progress with this, because I certainly
haven't...
In fact, as Bruce hinted, I'm not sure that it's even technically
possible...
So, in the meantime, I've gone with an IP blocking solution which has
killed the spammers dead in their tracks.
If anyone's interested, the IP addresses I've caught (so far!) are:
206.83.210.59
216.224.117.178
58.65.233.129
66.79.163.226
"John Timney (MVP)" <x_****@timney.eclipse.co.ukwrote in message
news:vu********************@eclipse.net.uk...
>I think a list of IP's would probably have to do, and as for blocking them
do it in the module as suggested and actually redirect them to one of the
large download sites. Stop them with some payback. I think I have this
written already on another server - might power it up and ressurect the
code, although it can only be 30 lines or so. Now if you could autoextract
the IP's by identifying they were a nusicance to your site, it would be a
useful little sytem......but I agree with Bruce also, not a lot you can do
other than blocking the IP's.
This is how I did it...
/* SQL Server */
CREATE TABLE [dbo].[tlkpBlockedIP](
[strIP] [varchar](15) NOT NULL,
CONSTRAINT [PK_tlkpBlockedIP] PRIMARY KEY CLUSTERED
(
[strIP] ASC
)WITH (PAD_INDEX = OFF, IGNORE_DUP_KEY = OFF) ON [PRIMARY]
) ON [PRIMARY]
CREATE PROCEDURE [dbo].[uspBlockedIPSelect]
AS
SELECT * FROM tlkpBlockedIP
/* Global.asax */
<%@ Application Language="C#" %>
<%@ Import Namespace="shared" %>
<%@ Import Namespace="System.Collections.Generic" %>
<%@ Import Namespace="System.Data" %>
<%@ Import Namespace="System.Data.SqlClient" %>
<script runat="server">
void Application_Start(object sender, EventArgs e)
{
SqlDataReader objDR = null;
try
{
List<stringlstBlockedIP = new List<string>();
objDR = CDataAccess.GetSqlDataReader("uspBlockedIPSelect") ;
while (objDR.Read())
{
lstBlockedIP.Add(objDR.GetString(0));
}
Application["lstBlockedIP"] = lstBlockedIP;
}
catch (Exception ex)
{
CApplication.GlobalExceptionHandler(ex);
}
finally
{
if (objDR != null)
{
if (!objDR.IsClosed)
{
objDR.Close();
}
objDR = null;
}
}
}
void Application_BeginRequest(object sender, EventArgs e)
{
try
{
if
(((List<string>)Application["lstBlockedIP"]).Contains(HttpContext.Current.Request.ServerVaria bles["REMOTE_ADDR"]))
{
HttpContext.Current.Response.StatusCode = 404;
HttpContext.Current.Response.SuppressContent = true;
HttpContext.Current.ApplicationInstance.CompleteRe quest();
return;
}
}
catch (Exception ex)
{
CApplication.GlobalExceptionHandler(ex);
}
}
}
</script>
Nice of you to share the code, that'll do it nicely. :)
--
--
Regards
John Timney (MVP)
VISIT MY WEBSITE: http://www.johntimney.com http://www.johntimney.com/blog
"Mark Rae" <ma**@markNOSPAMrae.comwrote in message
news:uy****************@TK2MSFTNGP05.phx.gbl...
"John Timney (MVP)" <x_****@timney.eclipse.co.ukwrote in message
news:vu********************@eclipse.net.uk...
>>I think a list of IP's would probably have to do, and as for blocking them
do it in the module as suggested and actually redirect them to one of the
large download sites. Stop them with some payback. I think I have this
written already on another server - might power it up and ressurect the
code, although it can only be 30 lines or so. Now if you could
autoextract the IP's by identifying they were a nusicance to your site, it
would be a useful little sytem......but I agree with Bruce also, not a lot
you can do other than blocking the IP's.
This is how I did it...
/* SQL Server */
CREATE TABLE [dbo].[tlkpBlockedIP](
[strIP] [varchar](15) NOT NULL,
CONSTRAINT [PK_tlkpBlockedIP] PRIMARY KEY CLUSTERED
(
[strIP] ASC
)WITH (PAD_INDEX = OFF, IGNORE_DUP_KEY = OFF) ON [PRIMARY]
) ON [PRIMARY]
CREATE PROCEDURE [dbo].[uspBlockedIPSelect]
AS
SELECT * FROM tlkpBlockedIP
/* Global.asax */
<%@ Application Language="C#" %>
<%@ Import Namespace="shared" %>
<%@ Import Namespace="System.Collections.Generic" %>
<%@ Import Namespace="System.Data" %>
<%@ Import Namespace="System.Data.SqlClient" %>
<script runat="server">
void Application_Start(object sender, EventArgs e)
{
SqlDataReader objDR = null;
try
{
List<stringlstBlockedIP = new List<string>();
objDR = CDataAccess.GetSqlDataReader("uspBlockedIPSelect") ;
while (objDR.Read())
{
lstBlockedIP.Add(objDR.GetString(0));
}
Application["lstBlockedIP"] = lstBlockedIP;
}
catch (Exception ex)
{
CApplication.GlobalExceptionHandler(ex);
}
finally
{
if (objDR != null)
{
if (!objDR.IsClosed)
{
objDR.Close();
}
objDR = null;
}
}
}
void Application_BeginRequest(object sender, EventArgs e)
{
try
{
if
(((List<string>)Application["lstBlockedIP"]).Contains(HttpContext.Current.Request.ServerVaria bles["REMOTE_ADDR"]))
{
HttpContext.Current.Response.StatusCode = 404;
HttpContext.Current.Response.SuppressContent = true;
HttpContext.Current.ApplicationInstance.CompleteRe quest();
return;
}
}
catch (Exception ex)
{
CApplication.GlobalExceptionHandler(ex);
}
}
}
</script>
"John Timney (MVP)" <x_****@timney.eclipse.co.ukwrote in message
news:Cs******************************@eclipse.net. uk...
Nice of you to share the code, that'll do it nicely. :)
Isn't that why these newsgroups exist...? :-) This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: J C-W |
last post by:
I have a directory with files (of various formats) contained within a
website which uses PHP to control user access via session variables. I would
like to protect the directory from direct external...
|
by: Matt |
last post by:
I have an interactive web page that I need to prevent refreshes on.
The problem is that I want to ALLOW resubmissions, but only via the
submit button. My web page has two forms on it, one form for...
|
by: Robb Meade |
last post by:
Hi all,
A recent project that I had finished and went live with no apparant
problems.
My client received an email from a user who mentioned that by accident they
had been typing (over the...
|
by: Fred |
last post by:
Hi out there,
I have problems finding a way to warn a user that
another user intends soon to update the same specific row.
Let me explain.
User 1 get to a JSP "update customer record" page....
|
by: David Hane |
last post by:
Hi all,
I would like give users the ability to experiment with complex queries but
I'm worried about them creating queries that will bog down the server.
Does anyone have any ideas for...
|
by: Iain |
last post by:
I would like to prevent the user from closing MDI child windows. However, I
would like them to be able to minimize and maximize them.
Setting the Control Box to false removes the minimize and...
|
by: MarkMurphy |
last post by:
In a barebones website with one page, checking
HttpContext.Current.Request.UserLanguages.Length in Page_Load of an
ASPX page in the VS IDE in codebehind shows a value of 1. Then when I
refresh...
|
by: Mark Rae |
last post by:
Hi,
Because all my public sites are hosted with a 3rd-party ISP and, therefore,
I don't have access to their server's EventLog etc, every error is emailed
to me.
Recently, I've been getting...
|
by: tatata9999 |
last post by:
Thanks.
|
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: 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...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and...
| |
