Various questions about Tyk

Imported Google Group message. Original thread at: Redirecting to Google Groups Import Date: 2016-01-19 21:32:36 +0000.
Sender:Matthieu Nantern.
Date:Monday, 9 February 2015 16:22:02 UTC.

Hi !

I spend a day exploring and testing Tyk and it was cool ! I just have a few questions:
Where can I find the complete documentation for the user session object ?
Is it possible to change the clock skew for HMAC in configuration ?
What happen if Redis is down ? Our API is unreachable ?
Is there some specific configuration for Redis ? (like persistance for example)
Analytics in CSV is a little poor, is it possible to have stats per key ?
Is there any plan to support another DB ? Like Cassandra
Thank you for your answers!

Imported Google Group message.
Sender:Martin Buhr.
Date:Wednesday, 11 February 2015 10:57:16 UTC.

Hi,

Ah I see, yes there are best practices for high-availability Redis setups, but to be honest it’s not something we’ve documented. There are specialist documents and how-to’s on the web that cover how to set up clustered redis systems and there’s even SaaS setups that ensure uptime (including AWS ElastiCache, RedisLabs RedisHQ etc.).

Many thanks,
Maritn

  • show quoted text -

Imported Google Group message.
Sender:Martin Buhr.
Date:Monday, 9 February 2015 16:55:03 UTC.

Hi Matthieu,

Q: Where can I find the complete documentation for the user session object ?

A: Good question, there isn’t any, Will make a note to add that with the next release… for now, I can elaborate based on what’s in the tyk package: (see added comments)

type SessionState struct {
LastCheck int64 json:"last_check" // Deprecated, was used for rate limiting
Allowance float64 json:"allowance" // Rate limit max
Rate float64 json:"rate" // Rate limiting
Per float64 json:"per" // Rate limiting (see here for docs on these fields: https://tyk.io/v1.4/quotas-limits-security/access-control/)
Expires int64 json:"expires" // Expiry in Unix timestamp
QuotaMax int64 json:"quota_max" // Maximum quota for period
QuotaRenews int64 json:"quota_renews" // Timestamp of when the key renews (much like a really long throttler)
QuotaRemaining int64 json:"quota_remaining" // Quota remaining
QuotaRenewalRate int64 json:"quota_renewal_rate" // When the quota renews in seconds
AccessRights map[string]AccessDefinition json:"access_rights" // Access rights define which API and version this user has access to see https://tyk.io/v1.4/quotas-limits-security/limiting-access/
OrgID string json:"org_id" // the organisation ID this user belongs to, used for securing certain access rights across API’s in a mutli-org envrironment
OauthClientID string json:"oauth_client_id" // Oauth data, see the Oauth flows section for all of these, it’s complicated
BasicAuthData struct {
Password string json:"password" // If basic auth is set, this is where the password lives, soon to be encrypted, currently plaintext
} json:"basic_auth_data"
HMACEnabled bool json:"hmac_enabled" // Is HMAC enabled?
HmacSecret string json:"hmac_string" // HMAC secret
IsInactive bool json:"is_inactive" // Is the key active, set this to true and the key will no longer work, BUT it will not be deleted
MetaData interface{} json:"meta_data" // This is a hasmap you can set to store metadata unrelated to tyk, e.g. avatar, homepage, first name, last name etc. Is accessible from custom middleware
}

Q: Is it possible to change the clock skew for HMAC in configuration ?

A: Nope, though it really should be… Can you raise aticket?

Q: What happen if Redis is down ? Our API is unreachable ?

A: Pretty much, all the keys are stored in Redis, so Tyk would be unable to validate any keys that are inbound nor would any throttling or quota management work.

Q: Is there some specific configuration for Redis ? (like persistance for example)

There are some options for Redis in the tyk.conf file, though not much except key data is stored in Redis, and it’s persistence is controlled by the expires value. Also, in an ApI Defintion you can set the Session lifetime to destroy keys after a specific lifetime (e.g. if no keys should ever exist forever). Could you elaborate?

Q: Analytics in CSV is a little poor, is it possible to have stats per key ?

The CSV purger is pretty underdeveloped, adding those vaues would be pretty simple as the analytics that get sent to Mongo have by key, upstream latency and a whole host of extra data that is missing in the CSV data. It just hasn’t had the love it needs because we don’t feel many people use it. Please rais ea ticket and we’ll get to bulking out the data in time, because we track a lot of granular stuff.

A: Is there any plan to support another DB ? Like Cassandra

Currently, no - although we have made the storage handlers an interface in the source code, so it is replaceable so long as the core methods are implemented. Are you looking to replace Redis or Mongo? Mongo would be more difficult, we use it’s aggregation pipelines to do the number crunching for the analytics package, so it’s unlikely we’ll mve away from that (quit e alot of invested dev there). However Redis could be exchanged. We would need to know form the community which DB would be best to start with. Might be an idea to start a poll :slight_smile:

It is definitely possible, we’ve just focussed on Redis because of it’s speed, for a web proxy it’s important to have very very fast key store.

Hope that clarifies things - any other questions let me know :slight_smile:

Cheers,
Martin

  • show quoted text -

Imported Google Group message.
Sender:Martin Buhr.
Date:Wednesday, 11 February 2015 10:39:22 UTC.

Hi,

It’s a lot more clear, thank you !

I submitted 2 issues (clock skew and csv analytics).

My main concern about Tyk is the High Availability regarding Redis. Redis is great for performance and I really like it but losing all our api if one redis is down doesn’t seem good to me.
That’s why I wanted to know if there is any “best practices” to configure Redis (like replication, data persistance or other ? twemproxy…).

As for the replacement of the DB I was thinking about MongoDB but your answer is clear you use MongoDB for analytics. For us it’s a good thing that Mongo is optional because we have already another NoSQL DB (Cassandra).

Thanks !

  • show quoted text -

Imported Google Group message.
Sender:Matthieu Nantern.
Date:Wednesday, 11 February 2015 10:57:16 UTC.

Hi,

Ah I see, yes there are best practices for high-availability Redis setups, but to be honest it’s not something we’ve documented. There are specialist documents and how-to’s on the web that cover how to set up clustered redis systems and there’s even SaaS setups that ensure uptime (including AWS ElastiCache, RedisLabs RedisHQ etc.).

Many thanks,
Maritn

  • show quoted text -

Imported Google Group message.
Sender:Martin Buhr.
Date:Wednesday, 11 February 2015 10:58:15 UTC.

Ok, thanks for your answer !

  • show quoted text -

Imported Google Group message.
Sender:Martin Buhr.
Date:Tuesday, 1 December 2015 10:55:49 UTC.

Can you give an update on the Basic Auth password encryption? is planned in the near future?

  • show quoted text -

Imported Google Group message.
Sender:Matthieu Nantern.
Date:Tuesday, 1 December 2015 11:11:07 UTC.

BA Password encryption will be the default in v1.9 - we’re using bcrypt, it will be backwards compatible. v1.9 is almost ready to ship.