10

Watched 10 videos

Watched 10 Videos from start to finish
6/10

Spread the word 1 time

Referred 1 Member to Drifting Ruby

500

500 times Chatter Box

Make 500 comments to videos or replies to other comments
319/500

4

Suggested 4 episodes

Helped the community by suggesting 4 episodes
3/4

128

Vote Suggestion 128 times

Helped the community by voting on suggestions 128 times
64/128

Watched 1 video

Watched 1 Video from start to finish

Earned on 3/4/2019

Subscribed for 1 month

Learning and showing your support for 1 Month

Earned on 3/4/2019

3

Subscribed for 3 months

Learning and showing your support for 3 Months

Earned on 3/4/2019

6

Subscribed for 6 months

Learning and showing your support for 6 Months

Earned on 3/4/2019

12

Subscribed for 12 months

Learning and showing your support for 12 Months

Earned on 3/4/2019

18

Subscribed for 18 months

Learning and showing your support for 18 Months

Earned on 3/4/2019

24

Subscribed for 24 months

Learning and showing your support for 24 Months

Earned on 7/6/2019

1 time Chatter Box

Make 1 comment to videos or replies to other comments

Earned on 3/4/2019

10

10 times Chatter Box

Make 10 comments to videos or replies to other comments

Earned on 3/4/2019

50

50 times Chatter Box

Make 50 comments to videos or replies to other comments

Earned on 3/4/2019

kobaltz PRO said over 3 years ago on Rails API - Authentication with JWT :

By default, config/initializers/filter_parameter_logging.rb will filter the password

Rails.application.config.filter_parameters += [:password]

So, the logs would filter out the password and never be displayed in the logs. Whenever communicating with API, especially sending the password, you should always encrypt the communication with SSL. This is really no different than sending a POST request to a web login session. Unless the form is posted to an endpoint over SSL, the password would also be sent over plaintext.

Great questions!


kobaltz PRO said over 3 years ago on Rails API - Authentication with JWT :

If your application's traffic is not being served over SSL, anything that is sent or posted, would be essentially in plain text.  It was just illustrating the point that your worry about the API sending the plain text password would be the same worry for a login form. Unless the API endpoint as well as the login form are served over SSL, the password would have been sent over plaintext (and not encrypted via SSL). I suppose the confusion was plaintext. Technically, regardless, in both instances the password is sent as plaintext, but when served over an SSL connection, the plaintext password is protected.


kobaltz PRO said over 3 years ago on Rails API - Authentication with JWT :

With a user registration, it would function very similar to any other kind of form post that you would do. You should have some sort of registration endpoint within your API application that would create the user. You may have something like http://example.com/users/create where you would make an HTTP POST to via your app. You would pass in the parameters

{
  user: { 
    first_name: 'John',
    last_name: 'Doe',
    email: '[email protected]',
    password: '123456',
    password_confirmation: '123456'
  }
}

and your model would have the necessary validations to ensure password complexity, and email uniqueness. If the user is created, pass a successful response. Otherwise, you would respond with an error.

You would also need to provide an authenticate method for your user. In this example, we simply used devise to handle the user registration and authentication. While you could do something similar in an API only application, it might be a bit heavy. However, using the devise logic (not necessarily the views), will give you access to a lot of the built in functionality around locking out the user, confirmation signups, etc.

Depending on the architecture of your application, you can make the new user registration only available under the client portal. Also, if you are using some sort of role based authorization, make sure that you set the default access to a client role. 

Hope this helps!


kobaltz PRO said over 3 years ago on Caching with Dalli :

Only if your cache key included the updated_at attribute or similar. Part of the issue is also when you have a collection of records as you might find in Russian Doll Caching. Even if the individual record's cache is expired, you will still need to expire the outer cache (parent cache) as well since it is stale at this point.    



kobaltz PRO said over 3 years ago on Rails API - Authentication with JWT :

It is a Chrome Extension called Advanced REST Client.