> What I still don't get is how/why Google managed to
> crawl part of the admin site in question to start with.
My guess is that someone, somewhere, wrote a link to the admin URL in
a public web page.
Generally, you can find what pages link to your page in Google using
the "link:" operator.
Dav
> My understanding in talking with some Google reps is that
> the google-bot does not click submit buttons, but it does follow all
> links.
What I still don't get is how/why Google managed to crawl part of the
admin site in question to start with.
Yes, there were mistakes and "not best practic
On Monday 23 Feb 2009, Burns, John D wrote:
> the google-bot does not click submit buttons, but it does follow all
> links. Needless to say, the google-bot deleted all of the records where
> that was the case in this app. So, as an added precaution, use type="button"> or but do not use on
> any
-
From: Les Mizzell [mailto:lesm...@bellsouth.net]
Sent: Thursday, February 19, 2009 3:10 PM
To: cf-talk
Subject: Googlebot got me good last night...
This happened on a small site with a user admin system that's password
protected. Seems Googlebot managed to get into the admin system
> I guess the part I was wondering about was the logic for checking for
> both variables. Is there no other way to check if session management
> and client cookies are enabled? Don't know if you know the answer to
> this, but does CF automatically lose its session if one of those cookies
> are d
Dave Watts wrote:
> The point of cookies is that they're set once and kept for some
> duration; there's no need to set them on each subsequent page request
> (and it'll annoy people who've configured their browsers to prompt
> before accepting a cookie).
I guess the part I was wondering abou
>>> "CFTOKEN")>
>>> OK, that works, but I don't get exactly what it's doing.
>>
>> It replaces the two standard CF-generated cookies which don't expire
>> with two that will expire immediately the browser closes (the default
>> behaviour of cfcookie).
>
> btw, what's
>>> >> "CFTOKEN")>
>>>
>>>
>>>
>> OK, that works, but I don't get exactly what it's doing.
>
> It replaces the two standard CF-generated cookies which don't expire
> with two that will expire immediately the browser closes (the default
> behaviour of cfcookie).
btw, what's the purpo
>>> >> "CFTOKEN")>
>>>
>>>
>>>
>> OK, that works, but I don't get exactly what it's doing.
>
> It replaces the two standard CF-generated cookies which don't expire
> with two that will expire immediately the browser closes (the default
> behaviour of cfcookie).
Ahhh... and I had ju
Al Musella, DPM wrote:
> ever since then, I never use a link to make a change in my
> database. It is just too easy to trigger it by accident.
Google ran into the same issue with their web accelerator plugin a while
back. Too many people had actionable items behind links and it caused a
lot o
ginal Message-
From: Al Musella, DPM [mailto:muse...@virtualtrials.com]
Sent: Thursday, February 19, 2009 8:46 PM
To: cf-talk
Subject: Re: Googlebot got me good last night...Application.cfm question
Nobody else mentioned it yet, but I had something similar happen many
years ago - a link ch
Nobody else mentioned it yet, but I had something similar happen many
years ago - a link checking program was accidentally run on a
password protected area of the website and did a lot of funny things
to our database..
ever since then, I never use a link to make a change in my
database. It
This is where I should post links to "Fusebox 5 & FLiP" and "How To Drive
Fusebox 5.5" but protonarts.com is down. Anyone have any ideas and/or Jeff
Peters on speed dial...?
On Thu, Feb 19, 2009 at 6:48 PM, Justin Scott
wrote:
>
> Les Mizzell wrote:
> >> You have much to learn, young padawan, b
Les Mizzell wrote:
> Matt Quackenbush wrote:
>
>> > "CFTOKEN")>
>>
>>
>>
>
> OK, that works, but I don't get exactly what it's doing.
It replaces the two standard CF-generated cookies which don't expire
with two that will expire immediately the browser closes (the default
behaviour
Matt Quackenbush wrote:
> "CFTOKEN")>
>
>
>
Hey Matt,
I use that same code - how does it actually work? I never quite
understood how it accomplished the goal killing the session when you
closed the browser.
Thanks!
Mike
Matt Quackenbush wrote:
> "CFTOKEN")>
>
>
>
OK, that works, but I don't get exactly what it's doing.
~|
Adobe® ColdFusion® 8 software 8 is the most important and dramatic release to
date
Get the Free Trial
http://a
use j2ee sessions (setting in cf admin)
Azadi Saryev
Sabai-dee.com
http://www.sabai-dee.com/
Les Mizzell wrote:
>
> Right now, I can login, and go to a page in the admin folder, copy the
> address, close the browser, and for the next 10 minutes, still get back
> in simply by putting the page
~|
Adobe® ColdFusion® 8 software 8 is the most important and dramatic release to
date
Get the Free Trial
http://ad.doubleclick.net/clk;207172674;29440083;f
Archive:
http://www.houseoffusion.com/groups/cf-talk/mess
> ---
> Application
> ---
>
>
>
>
>
>
>
>
>
>
>
Right now, I can login, and go to a page in the admin folder, copy the
address, close the browser, and for the next 10 minutes, st
Les Mizzell wrote:
>> You have much to learn, young padawan, but you are in the right place.
>
> You're telling me. Fusebox 5.x has me tearing my hair out. Maybe
> somebody will release "Dummies Guide to Fusebox" at some point. I'm
> going to need it
There used to be books on Fusebox seve
http://tech.groups.yahoo.com/group/fusebox5/
On Thu, Feb 19, 2009 at 3:53 PM, Les Mizzell wrote:
> You're telling me. Fusebox 5.x has me tearing my hair out. Maybe
> somebody will release "Dummies Guide to Fusebox" at some point. I'm
> going to need it
~
read the fusebox 4 book from techspedition. While it's not completely
up-to-date, I think it would still help on the conceptual level. FB 5.x
still maintains backwards compatibility with 4.x applications with some
new features added, as documented on the FB site.
btw, if you want to make you
> You have much to learn, young padawan, but you are in the right place.
You're telling me. Fusebox 5.x has me tearing my hair out. Maybe
somebody will release "Dummies Guide to Fusebox" at some point. I'm
going to need it
~~
Aha - that kicks ass :) I wish I knew that when I was having a
discussion with the php developer telling me about the proxy ignoring
headers while he was also dissing cf!
Next time.
2009/2/19 Dave Watts :
> CFLOCATION aborts the processing of the current page. Any output
> generated before the C
> Just another note on this. I've heard of people setting up proxies
> that ignored all redirect headers sent back to them. This means that
> if you use cflocation to locate to your login page, you should also
> ensure that the requested page does not show up should the cflocation
> fail. ie.
>
>
> So,
> 1. Anybody else have this problem recently?
> 2. I'm an idiot I guess, how *should* I be doing my login systems?
> (One site on CF8, others still CF7)
> 4. If you're doing anything like I am, then maybe we're *all* idiots at
> this point and need to redo our login pages to use whateve
Les Mizzell wrote:
>
>
> alert("Your credentials could not be verified, please try
> again!!!");
>
>
>
Since CFLOCATION won't send your JavaScript output, you'll need to pass
your message along on the URL and have the login page look for
it/display it ins
Dominic Watson wrote:
> Just another note on this. I've heard of people setting up proxies
> that ignored all redirect headers sent back to them. This means that
> if you use cflocation to locate to your login page, you should also
> ensure that the requested page does not show up should the cfloc
Plus Google usually abides by robots.txt. Make sure you disallow your admin
pages/folders to all bots. At least this will stop the honest ones.
Wil Genovese
On Thu, Feb 19, 2009 at 2:41 PM, Dominic Watson <
watson.domi...@googlemail.com> wrote:
>
> Just another note on this. I've heard of p
How about:
---
login process:
---
alert("Your credentials could not be verified, please try
again!!!");
---
Application
---
Just another note on this. I've heard of people setting up proxies
that ignored all redirect headers sent back to them. This means that
if you use cflocation to locate to your login page, you should also
ensure that the requested page does not show up should the cflocation
fail. ie.
Or somesuch
I don't believe the googlebot can be stopped by Javascript, and nevertheless
it's probably never a really good idea to prevent access to admin pages with
JS only as disabling Javascript is relatively easy.
Using cflocation would probably take care of it, though, and effectively
redirects the user
force the browser to the login page.
William
-Original Message-
From: Les Mizzell [mailto:lesm...@bellsouth.net]
Sent: Thursday, February 19, 2009 12:10 PM
To: cf-talk
Subject: Googlebot got me good last night...
This happened on a small site with a user admin system that's p
>
>
>
>
>
>
>
> self.location="../admin_login.cfm";
>
>
>
Why are you using JS? I usually the login form. Never rely on JS
for anything like this.
Will
~~
Yeah, I hate to say it but
Your problem is that you are relying on Javascript as your security. Anybody
an tell their browser to ignore your security, thus they will not get
redirected to the login page.
You need to either use cflocation to redirect them to your login page or a
cfinclude of
This happened on a small site with a user admin system that's password
protected. Seems Googlebot managed to get into the admin system last
night, started crawling admin pages, and ended up munging half the database:
1. Clicking "archive" or "mark inactive" buttons on admin area
index pa
36 matches
Mail list logo
