[jira] Created: (AXIS2C-261) Password callback API needs redoing
Password callback API needs redoing
---
Key: AXIS2C-261
URL: http://issues.apache.org/jira/browse/AXIS2C-261
Project: Axis2-C
Issue Type: Improvement
Components: rampart
Affects Versions: Current (Nightly)
Reporter: James Clark
There are two distinct scenarios where Axis2/C might use the password:
1. There's an incoming message with a username and possibly digested password,
and Axis2/C needs to check whether the password is valid.
2. There's an outgoing message, and Axis2/C needs to know what username and
what password to use.
These are really, quite different situations with different requirements and
it's not a good idea to combine them into a single interface. Let's consider
them in turn.
1. The key point to bear in mind here is that you can't assume that the
password will be directly accessible. For example, the passwords may be stored
in a database that is readable by root but not by the Axis2/C userid; in this
case, password checking would be done by a separate daemon running as root
(like saslauthd) that provides a service over a Unix socket that accepts a
particular username/password pair and says whether or not it is valid. Or you
might be piggybacking on top of the apache2 authn provider interface.
typedef struct {
/* Given a username and password, expected to return AUTH_GRANTED
* if we can validate this user/password combination.
*/
authn_status (*check_password)(request_rec *r, const char *user,
const char *password);
/* Given a user and realm, expected to return AUTH_USER_FOUND if we
* can find a md5 hash of 'user:realm:password'
*/
authn_status (*get_realm_hash)(request_rec *r, const char *user,
const char *realm, char **rethash);
} authn_provider;
I would suggest what you need is an OO type rampart_authn_username_t with
methods similar to the following
axis2_status_t rampart_authn_username_check_password(rampart_authn_username_t
*, const axis2_env_t *, axis2_msg_ctx_t *, const axis2_char_t *username, const
axis2_char_t *password)
axis2_status_t
rampart_authn_username_check_password_digest(rampart_authn_username_t *, const
axis2_env_t *, axis2_msg_ctx_t *, const axis2_char_t *username, const char
*nonce, size_t nonce_length, const char *digest)
(nonce is the concatenation of the timestamp and nonce, ready for hashing;
digest is the binary 20-byte binary SHA-1 hash)
The message context is in there, because the realm (password database) to use
may depend on the message. You'll also need this in order to allow mod_axis2
to provide an implementation of this on top of the Apache auth providers (note
this won't work for password digests).
2. For the outgoing case, I would suggest an interface rampart_cred_username_t
like this:
axis2_status_t rampart_cred_username_get(rampart_cred_username_t *, const
axis2_env_t *, axis2_msg_ctx_t *, const char **username_res, const char
**password_res)
(the returned username/password will be owned by one of the context objects in
the context hierarchy)
This allows for a number of things not possible at the moment:
- different endpoints can have different username/passwords
- the user can be interactively asked for both the username and password; the
UI can provide a single dialog that allows both to entered at the same time
- the object can perform caching of the username/passwords at the appropriate
level of the context hierarchy, according to the particular policy that it
implements; for example, the username can be cached at the configuration level
(as now) and the password cached at the operation level
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2C-264) Introduce AXIS2_INTERNAL macro for use with non-static functions that are not exported from shared library
Introduce AXIS2_INTERNAL macro for use with non-static functions that are not exported from shared library -- Key: AXIS2C-264 URL: http://issues.apache.org/jira/browse/AXIS2C-264 Project: Axis2-C Issue Type: Improvement Affects Versions: Current (Nightly) Reporter: James Clark Priority: Minor I would recommend introducing an AXIS2_INTERNAL macro and using it in a similar way to AXIS2_EXTERN for every function that is not AXIS2_EXTERN and not static. In other words, every function would be declared as either AXIS2_EXTERN, AXIS2_INTERNAL or static. On Windows, this would map onto nothing (I think), but on Linux with gcc it would map onto __attribute__((visibility(hidden)). This allows gcc to generate better code. For more information, see http://people.redhat.com/drepper/dsohowto.pdf http://www.nedprod.com/programs/gccvisibility.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2C-265) axis2_string.h macro strangeness
axis2_string.h macro strangeness Key: AXIS2C-265 URL: http://issues.apache.org/jira/browse/AXIS2C-265 Project: Axis2-C Issue Type: Improvement Components: util Affects Versions: Current (Nightly) Reporter: James Clark Priority: Trivial I don't see how it's useful for axis2_string.h to provide macros like this: #define AXIS2_STRCMP(s1, s2) \ axis2_strcmp(s1, s2) Why not have the clients use axis2_strcmp directly? The macro just uglifies code that uses it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2C-267) Drop use of macros in method calls to improve backward compatibility of binary
Drop use of macros in method calls to improve backward compatibility of binary -- Key: AXIS2C-267 URL: http://issues.apache.org/jira/browse/AXIS2C-267 Project: Axis2-C Issue Type: Improvement Affects Versions: 0.93 Reporter: Samisa Abeysinghe There is a problem with our current approach of using macros for method calls. Our approach means that adding a method to a type is a binary-incompatible change, not a binary-compatible change. This makes our current approach not sustainable in the long-term. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2C-268) AXIS2_CRTICAL_FAILURE = AXIS2_CRITICAL_FAILURE
AXIS2_CRTICAL_FAILURE = AXIS2_CRITICAL_FAILURE --- Key: AXIS2C-268 URL: http://issues.apache.org/jira/browse/AXIS2C-268 Project: Axis2-C Issue Type: Improvement Components: util Affects Versions: Current (Nightly) Reporter: James Clark Priority: Minor critical has two is -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2C-269) Try to clean up axis2_stream
Try to clean up axis2_stream Key: AXIS2C-269 URL: http://issues.apache.org/jira/browse/AXIS2C-269 Project: Axis2-C Issue Type: Improvement Components: util Affects Versions: Current (Nightly) Reporter: James Clark Priority: Minor For doing encryption and signing right, it will be important to have a clean, minimal stream interface. axis2_stream is a bit crufty at the moment. Specifically, the get_type method is bogus: if you have an OO type (which stream should be), then you shouldn't have a method returning a type-code for each implementation. It only seems to be used in axis2_http_transport_utils_on_data_request. I don't understand what that's doing, but I'm fairly sure get_type is not the best way to it. I would also suggest having separate input and output streams (unless there are really cases where you need to have a random access stream that can be both read and written). Having both get_char and read in an interface is a bad idea. Have just read. You can implement get_char as a function on top of read. unget is a bad idea on your fundamental stream type. If you really need it, create a lookahead_stream derived from stream that provides this additional operation and forwards to an underlying regular stream. Providing a peek method is better than unget (it's clear what the semantics of multiple peeks are). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2C-269) Try to clean up axis2_stream
[ http://issues.apache.org/jira/browse/AXIS2C-269?page=comments#action_12433594 ] James Clark commented on AXIS2C-269: The output stream needs flush and close methods as well. Try to clean up axis2_stream Key: AXIS2C-269 URL: http://issues.apache.org/jira/browse/AXIS2C-269 Project: Axis2-C Issue Type: Improvement Components: util Affects Versions: Current (Nightly) Reporter: James Clark Priority: Minor For doing encryption and signing right, it will be important to have a clean, minimal stream interface. axis2_stream is a bit crufty at the moment. Specifically, the get_type method is bogus: if you have an OO type (which stream should be), then you shouldn't have a method returning a type-code for each implementation. It only seems to be used in axis2_http_transport_utils_on_data_request. I don't understand what that's doing, but I'm fairly sure get_type is not the best way to it. I would also suggest having separate input and output streams (unless there are really cases where you need to have a random access stream that can be both read and written). Having both get_char and read in an interface is a bad idea. Have just read. You can implement get_char as a function on top of read. unget is a bad idea on your fundamental stream type. If you really need it, create a lookahead_stream derived from stream that provides this additional operation and forwards to an underlying regular stream. Providing a peek method is better than unget (it's clear what the semantics of multiple peeks are). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2C-270) base64 encoding/decoding should be implemented as a stream
base64 encoding/decoding should be implemented as a stream -- Key: AXIS2C-270 URL: http://issues.apache.org/jira/browse/AXIS2C-270 Project: Axis2-C Issue Type: Improvement Components: util Affects Versions: Current (Nightly) Reporter: James Clark Priority: Minor You should have something like this axis2_output_stream_t *axis2_create_base64_output_stream(axis2_output_stream_t *, const axis2_env_t *); Let's call the argument stream s1 and the returned stream s1. When you write bytes on s2, they will be written out as base64 encoded bytes on s2. Similarly, mapping base64 to binary is an input_stream. This allows you to efficiently deal with encoding/decoding large quantities of base64 data. You can have your existing functions as well. They should both be implemented on top of a lower-level layer that copies from buffer to buffer without doing allocation, e.g. something like base64_decode(const char *from, size_t from_length, char *to, size_t to_length, size_t *n_read, size_t *n_written) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2C-271) axiom_xml_reader/writer should read/write from streams
axiom_xml_reader/writer should read/write from streams -- Key: AXIS2C-271 URL: http://issues.apache.org/jira/browse/AXIS2C-271 Project: Axis2-C Issue Type: Improvement Components: xml/parser Affects Versions: Current (Nightly) Reporter: James Clark axiom_xml_reader/writer should read/write from axis2_streams. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2C-272) encryption/decryption should work on streams
encryption/decryption should work on streams Key: AXIS2C-272 URL: http://issues.apache.org/jira/browse/AXIS2C-272 Project: Axis2-C Issue Type: Improvement Components: rampart Affects Versions: Current (Nightly) Reporter: James Clark encryption/decryption should work on streams. axis2_output_stream_t *create_encryption_stream(..., axis2_output_stream *encrypted_stream) Writing output on the returned stream should cause the corresponding binary (not base64-encoded) encrypted bytes to be written to encrypted_stream. Similarly, for decryption axis2_input_stream *create_decryption_stream(..., axis2_input_stream *encrypted_stream) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2C-273) rampart_generate_nonce should not use rand()
rampart_generate_nonce should not use rand() Key: AXIS2C-273 URL: http://issues.apache.org/jira/browse/AXIS2C-273 Project: Axis2-C Issue Type: Bug Components: rampart Affects Versions: Current (Nightly) Reporter: James Clark It's not thread-safe and it's not cryptographically strong. I believe openssl provides some functions for random number generation; use them instead. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2C-274) rampart_generate_time should use date time stuff from util
rampart_generate_time should use date time stuff from util -- Key: AXIS2C-274 URL: http://issues.apache.org/jira/browse/AXIS2C-274 Project: Axis2-C Issue Type: Improvement Components: util Affects Versions: Current (Nightly) Reporter: James Clark Priority: Minor rampart_generate_time looks suspicious to me. It shouldn't be calling system functions directly. This sort of thing belongs in util. Why isn't it using axis2_date_time_*? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (AXIS2C-268) AXIS2_CRTICAL_FAILURE = AXIS2_CRITICAL_FAILURE
[ http://issues.apache.org/jira/browse/AXIS2C-268?page=all ] Samisa Abeysinghe resolved AXIS2C-268. -- Fix Version/s: 0.94 Resolution: Fixed Assignee: Samisa Abeysinghe Fixed AXIS2_CRTICAL_FAILURE = AXIS2_CRITICAL_FAILURE --- Key: AXIS2C-268 URL: http://issues.apache.org/jira/browse/AXIS2C-268 Project: Axis2-C Issue Type: Improvement Components: util Affects Versions: Current (Nightly) Reporter: James Clark Assigned To: Samisa Abeysinghe Priority: Minor Fix For: 0.94 critical has two is -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Codegen problem
When I codegen for a WSDL, I get parameters with no type in generated C
code.
The WSDL has
wsdl:message name='saveMessage' /
and I get the C code:
axis2_status_t axis2_ServerAdmin_save (const axis2_env_t* env , param20 );
Java generated code is correct:
public void save ( ) {}
So obviously in the generated C code, param20 should not be there (or at
least it has to be void, but that is not neat)
I deem that this is a problem with C template, but I could not locate
where exactly. Please help fix this.
Thanks
Samisa...
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Codegen problem
BTW I used '-d none' and '-u' in when generating code in both languages.
Samisa...
Samisa Abeysinghe wrote:
When I codegen for a WSDL, I get parameters with no type in generated
C code.
The WSDL has
wsdl:message name='saveMessage' /
and I get the C code:
axis2_status_t axis2_ServerAdmin_save (const axis2_env_t* env ,
param20 );
Java generated code is correct:
public void save ( ) {}
So obviously in the generated C code, param20 should not be there (or
at least it has to be void, but that is not neat)
I deem that this is a problem with C template, but I could not locate
where exactly. Please help fix this.
Thanks
Samisa...
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Axis2]Re: Codegen problem
Prefix corrected!
BTW I used '-d none' and '-u' in when generating code in both languages.
Samisa...
Samisa Abeysinghe wrote:
When I codegen for a WSDL, I get parameters with no type in generated
C code.
The WSDL has
wsdl:message name='saveMessage' /
and I get the C code:
axis2_status_t axis2_ServerAdmin_save (const axis2_env_t* env ,
param20 );
Java generated code is correct:
public void save ( ) {}
So obviously in the generated C code, param20 should not be there (or
at least it has to be void, but that is not neat)
I deem that this is a problem with C template, but I could not locate
where exactly. Please help fix this.
Thanks
Samisa...
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Axis2] Problem in codegen with ADB
I tried to codegen with '-d adb' and for both C and Java I get an error shown below. Any clues as to what may have caused the problems? Samisa... Exception in thread main org.apache.axis2.wsdl.codegen.CodeGenerationException: org.apache.axis2.wsdl.codegen.CodeGenerationException: No proper databinding has taken place at org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:224) at org.apache.axis2.wsdl.WSDL2Code.main(WSDL2Code.java:32) at org.apache.axis2.wsdl.WSDL2Java.main(WSDL2Java.java:21) Caused by: org.apache.axis2.wsdl.codegen.CodeGenerationException: No proper databinding has taken place at org.apache.axis2.wsdl.codegen.extension.DefaultDatabindingExtension.engage(DefaultDatabindingExtension.java:37) at org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:177) ... 2 more - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2]Re: Codegen problem
I corrected the problem in the templates. Please see whether it works
for you now :)
On 9/9/06, Samisa Abeysinghe [EMAIL PROTECTED] wrote:
Prefix corrected!
BTW I used '-d none' and '-u' in when generating code in both languages.
Samisa...
Samisa Abeysinghe wrote:
When I codegen for a WSDL, I get parameters with no type in generated
C code.
The WSDL has
wsdl:message name='saveMessage' /
and I get the C code:
axis2_status_t axis2_ServerAdmin_save (const axis2_env_t* env ,
param20 );
Java generated code is correct:
public void save ( ) {}
So obviously in the generated C code, param20 should not be there (or
at least it has to be void, but that is not neat)
I deem that this is a problem with C template, but I could not locate
where exactly. Please help fix this.
Thanks
Samisa...
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Ajith Ranabahu
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2C-275) apache2_stream_write should use ap_rwrite, not ap_rputs
apache2_stream_write should use ap_rwrite, not ap_rputs --- Key: AXIS2C-275 URL: http://issues.apache.org/jira/browse/AXIS2C-275 Project: Axis2-C Issue Type: Bug Components: transport/http Affects Versions: Current (Nightly) Reporter: James Clark Surely apache2_stream_write should use ap_rwrite rather than ap_rputs. Apart from being inefficient, using ap_rputs won't work if the output has nuls. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
