NoodlesOodles (sidenote: .gitignore)

For Flatiron’s Ruby on Rails Portfolio Project.

I was sitting in my room, thinking about what to do…i saw a packet of noodles on my desk and went with that…

NoodlesOodles (because Oodles of Noodles is taken already).

This app has at at least one has_many relationship
Brand has_many :noodles
Noodle has_many :reviews
Noodle has_many :users
User has_many :noodles
User has_many :brands
User has_many :reviews

it has at least one belongs_to relationship
Brand belongs_to :user
Noodle belongs_to :brand
Noodle belongs_to :user
Review belongs_to :user
Review belongs_to :noodle

it has at least two has_many through relationships
Noodle has_many :users, through: :reviews
User has_many :reviewed_noodles, through: :reviews, source: :noodle

it has at least one many-to-many relationship
User has_many :reviewed_noodles, through: :reviews, source: :noodle

this app has reasonable validations, including has_secure_password, presence: true, uniqueness

this app includes a class level ActiveRecord scope method,
scope :order_by_rating, -> {left_joins(:reviews).group(:id).order(‘avg(stars) desc’)}
which is utilized in the noodles#index

the app is able to signup, login, logout and also uses Omniauth to login Google and Github users.

so on and so forth.

now, let me tell you about the issue i had that cause a lot of headache and a lesson that will take a long time for me to forget…

.gitignore — a hard lesson i learned

i was setting up my omniauth for google and GitHub for the ruby on rails portfolio project.
i also decided to use AWS for image storage.

As per the Omniauth lesson ( on, i did the following:

“Instead of setting environment variables directly in our local ENV hash, we’re going to let an awesome gem handle the hard work for us. dotenv-rails is one of the best ways to ensure that environment variables are correctly loaded into the ENV hash in a secure manner. Using it requires four steps: 1. Add dotenv-rails to your Gemfile and bundle install. 2. Create a file named .env at the root of your application (in this case, inside the omniauth_readme/ directory). 3. Add your Facebook app credentials to the newly created .env file 4. Add .env to your .gitignore file to ensure that you don’t accidentally commit your precious credentials.”

i created a “.env” file in the root of the app and pasted client_id and secret in it for google, github and AWS.

after setting up and testing out the logins, i committed and called it a day because i had housework and other things i needed to do.
later on, i was skimming my email and i saw in the inbox a several of emails from AWS saying, sign-up confirmation…welcome to AWS…your AWS account is ready.

i did not open the 5+ emails i got from AWS because i hadn’t finished all my other work, so i pushed it off to the next day.

the following day, i did some more work on the project, committed and pushed it to GitHub.
i opened the AWS emails, one by one…thank you for signing up…thank you for creating…welcome to AWS…
and then the THIRD EMAILS: ACTION REQUIRED: YOUR AWS account is compromised…
i didn’t see how that could’ve happened because i just created the AWS account the day before.
i checked through all of the AWS emails and sure enough my account was compromised, the limits on the free-trial were all used up and i was charged over $100.
one of the emails from AWS said that the contents of the “.env” file was on
Lo and behold, the AWS Access Key, along with the corresponding Secret Key is publicly available online

the “.env” file was pushed to GitHub.

i don’t know how it happened, but i’m sure it was because of the long day i was having already, that i forgot to add the “.env” file to the “.gitignore” file before committing and pushing to GitHub.

Within 2 hours of creating the AWS account, it was compromised. you know what, i think there are bots searching for .env files on GitHub.

i emailed AWS back and forth on what to do. AWS said i had change my password (no big deal), but the following was took a lot of time, because i had no idea what they were talking about and had to read a lot on how to do it, navigate through a confusing website and make sure i changed/deleted exactly what was prescribed (and there was +40 changes and deletions over multiple regions):

Delete the Access keys:
If your application uses the access key, you need to replace the exposed key with a new one. To do this, first create a second key (at that point both keys will be active) and modify your application to use the new key.
Then disable (but do not delete) the first key. If there are any problems with your application, you can make the first key active again. When your application is fully functional with the first key inactive, please delete the first key.

Delete all keys created prior to compromise date (root account):
If you are not using the access key, you can simply delete it. To delete the exposed key, visit the “Security Credentials” page here:
Your keys will be listed in the “Access Keys” section.

Delete all keys created prior to compromise date (IAM users):
Navigate to your IAM Users list in the AWS Management Console, here: Please select the IAM user identified above.
Click on the “User Actions” drop-down menu and then click “Manage Access Keys” to show that user’s active Access Keys. Click “Delete” next to the access key identified above.
For detailed instructions to re-secure your account, please visit the link below:

all this took hours, over a couple of days, to do.

all this because i somehow forgot to add “.env” to the “.gitignore” file.

at the end, i was refunded the +$100 that i was charged and i learned a huge lesson from it, one that i won’t forget for a while.


Hello, I am a young enthusiastic Software Engineer. Looking forward to an opportunity to use my skills for mutual benefits and growth as well.