Issues - relevance/castronaut

relevance / castronaut

Description:

CAS Server

Sort by: Priority | Votes | Last Updated

Loading…

1.

0 votes

feature
x

RESTful authentication responses
1 comment Created 6 months ago by relevance

Title

Body
When a user posts credentials and authentication fails, CAStronaut still returns a 200 status. Shouldn’t the response use a HTTP status code to indicate that the authentication fails, perhaps 401 or 403? Technically, I see that 200 is okay as the post succeeded and the server is returning the result. However, doesn’t it also make sense to tell the client itself (not the user) that the auth event failed? [original LH ticket](http://relevance.lighthouseapp.com/projects/18757/tickets/15) This ticket has 0 attachment(s).
or cancel

When a user posts credentials and authentication fails, CAStronaut still returns a 200 status. Shouldn’t the response use a HTTP status code to indicate that the authentication fails, perhaps 401 or 403?

Technically, I see that 200 is okay as the post succeeded and the server is returning the result. However, doesn’t it also make sense to tell the client itself (not the user) that the auth event failed?

original LH ticket

This ticket has 0 attachment(s).

Comments

relevance Sun May 17 07:12:03 -0700 2009 | link

RESTful authentication responses

An interesting update on this. While .htaccess files allow redirects w/ a 401 error, the spec doesn’t provision for 401 w/ redirection. As such, it would seem that in a SOA/REST scenario 401 would be beneficial, but not for GUIs.

I see two straightforward options:

#1: check user agent. Use 200/302 for browsers when auth fails, and user 401 for non-browser clients.
#2: use different routs. Perhaps /rest_login for RESTful responses, and /login for browsers, and have / be a redirect to /login.

I don’t really like either of these, but I think #2 is better. There are a few other options that would work if neither of these is satisfactory...

by Tom Macklin

Comment
**RESTful authentication responses** An interesting update on this. While .htaccess files allow redirects w/ a 401 error, the spec doesn’t provision for 401 w/ redirection. As such, it would seem that in a SOA/REST scenario 401 would be beneficial, but not for GUIs. I see two straightforward options: #1: check user agent. Use 200/302 for browsers when auth fails, and user 401 for non-browser clients. #2: use different routs. Perhaps /rest_login for RESTful responses, and /login for browsers, and have / be a redirect to /login. I don’t really like either of these, but I think #2 is better. There are a few other options that would work if neither of these is satisfactory... by Tom Macklin
or cancel

Parsed with GitHub Flavored Markdown
4.

0 votes

bug
x

error when TGT not found in database?
0 comments Created 6 months ago by relevance

Title

Body
Is this spec supposed to pass? it "returns a Ticket that is valid when it cannot find a TGT" do TicketGrantingTicket.stub!(:find_by_ticket).return(nil) TicketGrantingTicket.validate_cookie(’abc’).should be_valid end I would think it shouldn’t be valid, but when you add this spec for TGT, it passes. [original LH ticket](http://relevance.lighthouseapp.com/projects/18757/tickets/13) This ticket has 0 attachment(s).
or cancel

Is this spec supposed to pass?

it "returns a Ticket that is valid when it cannot find a TGT" do
TicketGrantingTicket.stub!(:find_by_ticket).return(nil) TicketGrantingTicket.validate_cookie(’abc’).should be_valid end

I would think it shouldn’t be valid, but when you add this spec for TGT, it passes.

original LH ticket

This ticket has 0 attachment(s).

Comments

Parsed with GitHub Flavored Markdown
5.

0 votes

feature
x

[feature] support for better error message reporting
1 comment Created 6 months ago by relevance

Title

Body
[original LH ticket](http://relevance.lighthouseapp.com/projects/18757/tickets/12) This ticket has 0 attachment(s).
or cancel

original LH ticket

This ticket has 0 attachment(s).

Comments

relevance Sun May 17 07:12:32 -0700 2009 | link

[feature] support for better error message reporting

Currently, if you have a TicketResult for alice’s session, you can determine if the cookie is valid, but n/n why it is invalid. Thus it can be difficult to decide whether or not to display TicketResult.message to the user. Perhaps something like Castronaut::Presenters::Login#set_message(ticket_result) could be called by represent!, which would inspect the ticket_result for specific error conditions and set the display message accordingly.

On a different but related note, parsing the error message for info is the method TicketResult uses for determining uses for determining validity, but that doesn’t seem to be a sustainable approach unless there’s going to be a convention for error messages in TicketResult instances.

by Tom Macklin

Comment
**[feature] support for better error message reporting** Currently, if you have a TicketResult for alice’s session, you can determine if the cookie is valid, but n/n why it is invalid. Thus it can be difficult to decide whether or not to display TicketResult.message to the user. Perhaps something like Castronaut::Presenters::Login#set_message(ticket_result) could be called by represent!, which would inspect the ticket_result for specific error conditions and set the display message accordingly. On a different but related note, parsing the error message for info is the method TicketResult uses for determining uses for determining validity, but that doesn’t seem to be a sustainable approach unless there’s going to be a convention for error messages in TicketResult instances. by Tom Macklin
or cancel

Parsed with GitHub Flavored Markdown
7.

0 votes

bug
x

spec for expired ticket passes, should fail
0 comments Created 6 months ago by relevance

Title

Body
ServiceTicket#expired? never actually returns true. Same for LoginTicket#expired? def expired? # Time.now - service_ticket.created_on > CASServer::Conf.service_ticket_expiry end I think created_on should also be created_at. [original LH ticket](http://relevance.lighthouseapp.com/projects/18757/tickets/10) This ticket has 0 attachment(s).
or cancel
ServiceTicket#expired? never actually returns true. Same for LoginTicket#expired?

def expired?
```
# Time.now - service_ticket.created_on > CASServer::Conf.service_ticket_expiry
```
end

I think created_on should also be created_at.

original LH ticket

This ticket has 0 attachment(s).
Comments

Parsed with GitHub Flavored Markdown
8.

1 vote

bug
x

serviceValidate should fail for renew hacks
1 comment Created 6 months ago by relevance

Title

Body
If I validate a service ticket with renew I get an authenticationSuccess, even if the ticket was required from a login without renew. This way I can remove the renew parameter from the login url and get authenticated without a new login. http://www.ja-sig.org/products/cas/overview/protocol/index.html 2.5.1. parameters "renew [OPTIONAL] - if this parameter is set, ticket validation will only succeed if the service ticket was issued from the presentation of the user’s primary credentials. It will fail if the ticket was issued from a single sign-on session." [original LH ticket](http://relevance.lighthouseapp.com/projects/18757/tickets/9) This ticket has 0 attachment(s).
or cancel

If I validate a service ticket with renew I get an authenticationSuccess, even if the ticket was required from a login without renew.
This way I can remove the renew parameter from the login url and get authenticated without a new login.

http://www.ja-sig.org/products/cas/overview/protocol/index.html
2.5.1. parameters
"renew [OPTIONAL] - if this parameter is set, ticket validation will only succeed if the service ticket was issued from the presentation of the user’s primary credentials. It will fail if the ticket was issued from a single sign-on session."

original LH ticket

This ticket has 0 attachment(s).

Comments

relevance Sun May 17 07:12:48 -0700 2009 | link

serviceValidate should fail for renew hacks

Great catch! I am fixing now.

by Aaron Bedra

Comment
**serviceValidate should fail for renew hacks** Great catch! I am fixing now. by Aaron Bedra
or cancel

Parsed with GitHub Flavored Markdown
11.

0 votes

feature
x

Support OpenID as an authentication handler
2 comments Created 6 months ago by relevance

Title

Body
The current castronaut implementation expects to see a login and password for authentication. OpenID provides only a URI. Since OpenID provides a common-login scheme and CAS provides a single-sign-on scheme, having OpenID authentication handled within CAS would be useful. Some references: * The JASIG CAS implementation already supports OpenID, per: http://www.ja-sig.org/wiki/display/CASUM/OpenID [original LH ticket](http://relevance.lighthouseapp.com/projects/18757/tickets/3) This ticket has 0 attachment(s).
or cancel

The current castronaut implementation expects to see a login and password for authentication. OpenID provides only a URI.

Since OpenID provides a common-login scheme and CAS provides a single-sign-on scheme, having OpenID authentication handled within CAS would be useful.

Some references:
* The JASIG CAS implementation already supports OpenID, per: http://www.ja-sig.org/wiki/display/CASUM/OpenID

original LH ticket

This ticket has 0 attachment(s).

Comments

relevance Sun May 17 07:13:11 -0700 2009 | link

Support OpenID as an authentication handler

by Aaron Bedra

Comment
**Support OpenID as an authentication handler** by Aaron Bedra
or cancel

relevance Sun May 17 07:13:13 -0700 2009 | link

Support OpenID as an authentication handler

by Aaron Bedra

Comment
**Support OpenID as an authentication handler** by Aaron Bedra
or cancel

Parsed with GitHub Flavored Markdown
12.

1 vote

bug
x

Gem dependency not defined
0 comments Created 5 months ago by chipiga

Title

Body
Gem dependency not defined at the gemspec file. So it doesn't install necessary gems.
or cancel

Gem dependency not defined at the gemspec file. So it doesn't install necessary gems.

Comments

Parsed with GitHub Flavored Markdown