I believe you can only do this if the user belongs to the same domain as the web server is in.
That way the credentials are passed in the background from the logged-in user to the domain and authentication happens in the background - you would never notice it, if authentication did not succeed the
1. I think the IP idea is a bad one, because, as you said, they can be
spoofed. Plus what if they're using a dynamic IP?
2. I think you can use a combination of 2 and 3; Use public key
authentication to establish identity at the start of the session (you
can bind that to an IP if you wish), an
On 4/10/06, Angus Johnson <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> Can anyone tell me whether I am right by making the following assumptions;
>
> To make sure the proper client is talking to our server over **HTTPS** with
> XML I can do the following to authenticate them:
> - validate their remote I
Hi,
Can anyone tell me
whether I am right by making the following assumptions;
To make sure
the proper client is talking to our server over **HTTPS** with XML I can do the
following to authenticate them:
- validate their
remote IP (apparently can be spoofed??) to the one we have on
file
-
how about a slightly different approach? store all the pdfs outside of the webroot. Then when a user logs in, create a symbolic link to the pdf uuid.pdf points to the pdf outside the web root. Then on session close (CF7) delete the sym link.
Then you can use CF based authentication not IIS stuff.A
I'm very interested to see if you come up with a solution for this,
we've been looking for something just like this.
Something that I'm still looking into, but it may be possible for the
pdf document to talk to the container page when your using the embedded
approach. So, maybe create a new o
Not really
what I'm after... I guess I want to set the value of 'cgi.auth_user'. I want to
'authenticate' the user, so they don't see the authentication dialog
box.
It's looking
to me that all this authentication is done client-side, so perhaps CF won't help
me in this case.
thanks!
Using ODBC drivers still I believe.
Could be wrong.
Cheers
Gareth.
David Harris wrote:
> Aren't some of the example DBs connect to access with just the file
> path to the Access DB?
>
> Have a look at those and see how they are done.
>
>
> >
>
>
--~--~-~--~~~---~
you could just do a QofQ WHERE id <> something
and if you use wrote:
> doesnt look like you can do a delete in QoQ
>
>
>
>
> On 4/7/06, Andrew Mercer <[EMAIL PROTECTED]> wrote:
> >
> > Does anyone know if there is something like queryDeleteRow() {the opersite
> of queryAddRow()} in CF?
> > googl
Aren't some of the example DBs connect to access with just the file
path to the Access DB?
Have a look at those and see how they are done.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"cfaussie" group.
To post t
I ask in case of any performance reasons not to do so.
I've left behind (previous project) an important tool/CFC that uses
this "leave behind query" method in important areas. If I've made a
faux pas in doing so, I'd like to know
On 4/10/06, Andrew Mercer <[EMAIL PROTECTED]> wrote:
> that
that is what I went with before the deleteRow functions came inOn 4/10/06, Barry Beattie <[EMAIL PROTECTED]
> wrote:is there anything wrong with doing a query to leave behind what you don't want?
select * from origQofQwhere not #condition#"On 4/6/06, Steve Onnis <
[EMAIL PROTECTED]> wrote:>> Just m
I know this is possible, Just wondering if anyone on the list is doing it?
If you are? how are you doing it? are you using a JDBC connector? if so?
which one?
Cheers
Gareth.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
is there anything wrong with doing a query to leave behind what you don't want?
select * from origQofQ
where not #condition#"
On 4/6/06, Steve Onnis <[EMAIL PROTECTED]> wrote:
>
> Just my opinion, but that UDF is yuk. Imagine looping over a large query
>
> -Original Message-
> Fro
14 matches
Mail list logo
