Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 0 additions & 16 deletions backend/problems/admin.py
Original file line number Diff line number Diff line change
Expand Up @@ -103,22 +103,6 @@ def save_model(self, request, obj, form, change):
obj.author = request.user
super().save_model(request, obj, form, change)

# Customize queryset for admin to potentially show more fields or filter
# def get_queryset(self, request):
# qs = super().get_queryset(request)
# return qs


# TestCase can also be registered separately if needed for direct management,
# but often managed inline with Problems.
# class TestCaseAdmin(admin.ModelAdmin):
# list_display = ('id', 'problem_id_display', 'order', 'is_sample', 'points')
# list_filter = ('problem', 'is_sample')
# search_fields = ('problem__title_i18n', 'input_data', 'expected_output_data')

# def problem_id_display(self, obj):
# return obj.problem.id
# problem_id_display.short_description = 'Problem ID'

admin.site.register(Tag, TagAdmin)
admin.site.register(Problem, ProblemAdmin)
Expand Down
6 changes: 3 additions & 3 deletions backend/users/adapters.py
Original file line number Diff line number Diff line change
Expand Up @@ -13,15 +13,15 @@ def pre_social_login(self, request, sociallogin):
# This method is called just before the user is logged in.
# We can use it to check if the user is new and needs to complete registration.
if sociallogin.is_existing:
return
return None

# There is no existing social account for this user.
# Check if a user already exists with the same email address.
try:
# This will fail if the user does not exist
_ = sociallogin.user
# If the user exists, we can just link the social account and log them in.
return
return None
except Exception:
# The user does not exist, so we need to redirect them to complete registration.
# We'll pass the email address as a query parameter.
Expand All @@ -33,4 +33,4 @@ def pre_social_login(self, request, sociallogin):
return HttpResponseRedirect(redirect_url)

# If we can't get an email, we'll just let allauth handle it.
return
return None
9 changes: 0 additions & 9 deletions backend/users/models.py
Original file line number Diff line number Diff line change
Expand Up @@ -38,12 +38,3 @@ class Roles(models.TextChoices):

def __str__(self):
return self.username

# You might add helper properties here later, e.g.:
# @property
# def is_problem_creator(self):
# return self.role in {self.Roles.PROBLEM_CREATOR, self.Roles.PROBLEM_VERIFIER, self.Roles.ADMIN}

# @property
# def is_problem_verifier(self):
# return self.role in {self.Roles.PROBLEM_VERIFIER, self.Roles.ADMIN}
4 changes: 0 additions & 4 deletions backend/users/serializers.py
Original file line number Diff line number Diff line change
Expand Up @@ -164,8 +164,4 @@ def save(self, **kwargs):
user = self.context["request"].user
user.set_password(self.validated_data["new_password1"])
user.save()
# Optionally, update session auth hash if using session authentication alongside JWT
# from django.contrib.auth import update_session_auth_hash
# if hasattr(self.context['request'], 'session'):
# update_session_auth_hash(self.context['request'], user)
return user
2 changes: 1 addition & 1 deletion backend/webcoder_api/celery.py
Original file line number Diff line number Diff line change
Expand Up @@ -10,7 +10,7 @@
# ``celery`` ships no type information in the lean type-check environment, so the
# imported ``Celery`` symbol is opaque (pyright cannot confirm it is callable).
# Cast it to a callable to construct the app without losing checking elsewhere.
_Celery = cast("type[Any]", Celery)
_Celery = cast(type[Any], Celery)
app = _Celery("webcoder_api")

# Using a string here means the worker doesn't have to serialize
Expand Down
20 changes: 11 additions & 9 deletions backend/webcoder_api/settings.py
Original file line number Diff line number Diff line change
Expand Up @@ -22,7 +22,12 @@
# See https://docs.djangoproject.com/en/5.2/howto/deployment/checklist/

# SECURITY WARNING: keep the secret key used in production secret!
SECRET_KEY = "django-insecure-tra1bid*d3-t-+a$uu+1k&l+-aqxrp5u_ezlg5*oa%h$9cg45o"
# Sourced from the environment; the insecure fallback is for local/dev only and
# MUST be overridden via DJANGO_SECRET_KEY in any real deployment.
SECRET_KEY = os.environ.get(
"DJANGO_SECRET_KEY",
"django-insecure-dev-only-change-me",
)

# SECURITY WARNING: don't run with debug turned on in production!
DEBUG = True
Expand Down Expand Up @@ -104,11 +109,11 @@
DATABASES = {
"default": {
"ENGINE": "django.db.backends.postgresql",
"NAME": "webcoder_db", # Replace with your database name
"USER": "webcoder_user", # Replace with your PostgreSQL username
"PASSWORD": "darkstarone", # Replace with your PostgreSQL password
"HOST": "localhost", # Or your PostgreSQL host
"PORT": "5432", # Or your PostgreSQL port
"NAME": os.environ.get("POSTGRES_DB", "webcoder_db"),
"USER": os.environ.get("POSTGRES_USER", "webcoder_user"),
"PASSWORD": os.environ.get("POSTGRES_PASSWORD", ""),

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bug: The environment variable names in settings.py (e.g., POSTGRES_PASSWORD) are inconsistent with the .env.example file, which will cause deployment failures.
Severity: CRITICAL

Suggested Fix

Update the .env.example file to use the new POSTGRES_* environment variable names (POSTGRES_DB, POSTGRES_USER, POSTGRES_PASSWORD, POSTGRES_HOST, POSTGRES_PORT) to match the changes made in settings.py. This ensures the example configuration is consistent with the application's requirements.

Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location: backend/webcoder_api/settings.py#L114

Potential issue: The environment variable names for database configuration were updated
in `settings.py` to use a `POSTGRES_*` prefix (e.g., `POSTGRES_PASSWORD`), but the
`.env.example` file was not updated and still refers to the old `DB_*` variables.
Consequently, anyone setting up the application using the example file will define
variables like `DB_PASSWORD`, which the application ignores. The code will then fall
back to using an empty string for `POSTGRES_PASSWORD`, causing database authentication
to fail and preventing the application from connecting to the database.

Did we get this right? 👍 / 👎 to inform future reviews.

"HOST": os.environ.get("POSTGRES_HOST", "localhost"),
"PORT": os.environ.get("POSTGRES_PORT", "5432"),
}
}

Expand Down Expand Up @@ -187,9 +192,6 @@
"email": {"required": True},
"password1": {"required": True},
}
DJ_REST_AUTH = {
"SIGNUP_FIELDS": ACCOUNT_SIGNUP_FIELDS,
}
SOCIALACCOUNT_PROVIDERS = {
"google": {
"SCOPE": [
Expand Down
Loading