relevance / castronaut Goto Github PK

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).

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).

Now that FF3 can support HttpOnly along w/ IE, HttpOnly cookie support makes sense as a security improvement. Rails also uses this as default.

https://rails.lighthouseapp.com/projects/8994/tickets/1046

This is probably an issue for rack as well, and perhaps that is the proper place to address this? I will post a ticket there as well.

original LH ticket

This ticket has 0 attachment(s).

spec/app/controllers/db/* and spec/app/controllers/log/* should be removed from the gemspec. From the looks of it, there may be some other graft that could be removed as well.

original LH ticket

This ticket has 0 attachment(s).

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).

try to login as <script>alert("hello")</script> and observe error message.

original LH ticket

This ticket has 0 attachment(s).

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).

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).

original LH ticket

This ticket has 0 attachment(s).

writing tests & specs for concurrency is seldom practical, so I am not sure what the current expectation is wrt CAStronaut & concurrency. However, it seems that support for concurrency is nominal right now. I think for starters we need to develop:

1. a concurrency benchmark (in lieu of a spec)
2. a recipe for clustering CAStronaut server instances
3. a means for improving concurrency in CAStronaut itself (connection pools, multithreading and the like)

original LH ticket

This ticket has 0 attachment(s).

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

Castronaut needs some documentation surrounding deployment stories

original LH ticket

This ticket has 0 attachment(s).