> Or why is it in 34 that the provider's internal session is expired?
I don't think it matters why the session is not valid anymore, as we cannot
make assumptions to the logic someone wants to implement in their custom
auth provider. In the example, however, you can just assume a time out.
> I th
Hi Thomas,
Am 03.12.2013 18:04, schrieb Thomas Eckert:
> Now suppose the following
>
> [...]
> 32 user fills in and submits form
> 32 custom auth provider receives the user credentials
> 33 custom auth provider looks up it's own session in it's module
> internal session cache
> 34 custom auth pro
There are two type of sessions:
* sessions by mod_session which are used to maintain a mapping between
user requests and "apache's session"
* sessions in my custom provider, which are used to prevent accessing the
underlying auth daemon if not necessary
The custom provider itself is fairly sim
On 03 Dec 2013, at 5:29 PM, Thomas Eckert wrote:
> This whole process is important for supporting two factor authentication - in
> my example with OTP - but I doubt this is the only use case. In general it's
> a good idea to let the auth providers know where the user credentials came
> from (e
I will assume a forms based login and cookie managed sessions but it is not
limited to this setup.
A user connects, is queried for authentication, submits credentials and is
subsequently allowed access. The session is established via a cookie. If
the user credentials were accepted by a custom prov
On 03 Dec 2013, at 1:27 PM, Thomas Eckert wrote:
> I have been having problems with mod_auth_form on returning DENIED from my
> custom auth provider. This provider has it's own module-local session cache,
> where stuff like accessible paths, credentials and the like are stored to
> avoid havin
I have been having problems with mod_auth_form on returning DENIED from my
custom auth provider. This provider has it's own module-local session
cache, where stuff like accessible paths, credentials and the like are
stored to avoid having to query an external (and expensive) authentication
daemon.
Justin Erenkrantz wrote:
--On Monday, March 1, 2004 11:57 PM -0800 Stas Bekman <[EMAIL PROTECTED]>
wrote:
AP_FTYPE_PROTOCOL. But what difference does it make as long as it sees
the
HTTP headers?
Because AP_FTYPE_PROTOCOL is request-level when you are using HTTP.
yes, but it won't see the heade
--On Monday, March 1, 2004 11:57 PM -0800 Stas Bekman <[EMAIL PROTECTED]> wrote:
AP_FTYPE_PROTOCOL. But what difference does it make as long as it sees the
HTTP headers?
Because AP_FTYPE_PROTOCOL is request-level when you are using HTTP.
But, you should not be changing HTTP headers in a filter.
Andrà Malo wrote:
* Stas Bekman <[EMAIL PROTECTED]> wrote:
Why should a connection-level filter know about HTTP requests? --
justin
Because that's the only way to write a filter that processes HTTP headers
only.
Hmm. FTPYPE_PROTOCOL (sp?) is for such a purpose. If it's no applicable,
we'd nee
* Stas Bekman <[EMAIL PROTECTED]> wrote:
> > Why should a connection-level filter know about HTTP requests? --
> > justin
>
> Because that's the only way to write a filter that processes HTTP headers
> only.
Hmm. FTPYPE_PROTOCOL (sp?) is for such a purpose. If it's no applicable,
we'd need to
ent count one can tell when a new
request
is coming in over the keepalive connection. This technique is now
documented
in the mod_perl land:
Sorry, but I think something is off here.
Why should a connection-level filter know about HTTP requests? -- justin
Because that's the only way to
--On Monday, March 1, 2004 8:18 PM -0800 Stas Bekman <[EMAIL PROTECTED]> wrote:
Answering my own question, the solution is to use conn->keepalives counter
which is incremented at the end of each request. By storing the previous
count and comparing with the current count one can tell w
Stas Bekman wrote:
If I'm inside an input connection filter and want to be able to tell one
HTTP request from another what should I do? Counting Content-length is
ineffective, and a won't work if C-L header is wrong.
I can tell the end of HTTP headers section from the request body, by
If I'm inside an input connection filter and want to be able to tell one HTTP
request from another what should I do? Counting Content-length is ineffective,
and a won't work if C-L header is wrong.
I can tell the end of HTTP headers section from the request body, by matching
/^[\r\
On Tue, 11 Jun 2002, William A. Rowe, Jr. wrote:
> At 01:24 PM 6/11/2002, Aaron Luo wrote:
>
> >I am a software developer. But currently unemployeed right. I would like
> >to do some volunteer work. Anyone can give me a hint how to get some work
> >from this site? What is criteria to get some w
At 01:24 PM 6/11/2002, Aaron Luo wrote:
>I am a software developer. But currently unemployeed right. I would like
>to do some volunteer work. Anyone can give me a hint how to get some work
>from this site? What is criteria to get some work? Thanks.
Good question [many lurkers to this list prob
Aaron Luo <[EMAIL PROTECTED]> writes:
> I am a software developer. But currently unemployeed right. I would
> like to do some volunteer work. Anyone can give me a hint how to get
> some work from this site? What is criteria to get some work? Thanks.
Work is not handed out or assigned. Members o
I am a software developer. But currently unemployeed right. I would like to do some volunteer work. Anyone can give me a hint how to get some work from this site? What is criteria to get some work? Thanks.Do You Yahoo!?
Sign-up for Video Highlights of 2002 FIFA World Cup
20 matches
Mail list logo
