Marwadi University Students: Building a Spring Security Login Module as an Internship Deliverable

Yes, a Spring Security login module is a realistic deliverable for a two-week internship, if you keep the scope tight: registration, BCrypt password hashing, two roles and safe session handling. The checklist, 14-day plan and self-review rubric below show what “done” looks like and which beginner mistakes reviewers spot first.

What a reviewable login module contains in a 14-day internship

A login module is small enough to finish in two weeks but touches almost every basic security idea a Java backend developer needs: input validation, credential storage, authorization and state management. That is why it works well as a portfolio piece. A reviewer can open the repository, run it in minutes and judge your habits.

The free two-week online internship at CareerSwami includes an offer letter and a completion certificate after successful completion, and a working, documented module gives you something concrete to show for those 14 days. The internship does not promise a stipend, academic credit or a job, so treat the deliverable as evidence of skill, not as a guarantee of anything.

Scope for this article:

• A Spring Boot app with server-side sessions (not JWT; that is a separate topic).
• A user table in a relational database (H2 for development, MySQL or PostgreSQL optional).
• Registration, login, logout, a protected page for any logged-in user and an admin-only page.
• A README that explains how to run it and what you deliberately left out.

Fourteen-day plan for the Spring Security login module

Build checklist: registration, hashing, roles and sessions

Registration checklist

• Use a separate request object (for example RegistrationForm) instead of binding the form straight to the User entity. This stops users from submitting a field like role=ADMIN.
• Validate on the server with Bean Validation: @NotBlank, @Email, and a @Size minimum on the password.
• Normalise the email (trim, lower-case) before saving and put a unique constraint on that column in the database, not only in Java code.
• Assign the default role in the service layer, never from form input.
• Return a generic message on failure where it matters; do not leak internals through stack traces.

Password hashing checklist

• Declare a PasswordEncoder bean, using BCryptPasswordEncoder or PasswordEncoderFactories.createDelegatingPasswordEncoder().
• Encode the password once, in the registration service, before the entity is saved.
• Store only the hash, in a column long enough for it (60 characters for BCrypt, with some spare room is sensible).
• Never log the raw password, the hash or the full request body.
• Do not write your own hashing, and never use plain MD5 or SHA-1 for passwords.

Roles and authorization checklist

• Keep roles simple: a Role enum or a small table with USER and ADMIN.
• Configure a SecurityFilterChain bean (the current style; the old WebSecurityConfigurerAdapter is removed in recent Spring Security versions).
• Permit only the public pages (home, login, register, static files); make everything else require authentication; restrict /admin/** to ADMIN.
• Remember the ROLE_ prefix: hasRole("ADMIN") expects an authority named ROLE_ADMIN.
• Seed the first admin through a startup runner or SQL script that reads the password from configuration, not from a hard-coded string in the repo.

Session handling checklist

• Keep Spring Security’s default session fixation protection; do not switch it off.
• Set a sensible session timeout in configuration and mention it in the README.
• Configure logout to invalidate the session and delete the session cookie.
• Leave CSRF protection enabled for form-based pages; Thymeleaf adds the token to forms automatically.
• Set cookie flags (HttpOnly, and Secure when running over HTTPS) in application properties.
• Send users to the login page for unauthenticated access, and a clear 403 page for authenticated users without the right role.

Security self-review rubric: beginner mistakes to score before you submit

Score each row 0 (present and broken), 1 (partly handled) or 2 (handled and verified by you). A total below 18 out of 24 means another pass before submission.

Illustrative example: scoring a draft login module

The following is a made-up scenario for explanation only; no code was run to produce it. Suppose a student finishes day 10 and reviews the draft against the rubric.

• Row 1: the database shows BCrypt hashes. Score 2.
• Row 2: the registration controller accepts a User object directly, so a hidden role field would work. Score 0. Fix: create a RegistrationForm with only name, email and password, and set the role in the service.
• Row 4: CSRF was disabled during testing with a REST client and never turned back on. Score 0. Fix: re-enable it and use the Thymeleaf form tag, which adds the token.
• Row 6: the seeded admin password sits in a Java class. Score 1. Fix: move it to an environment variable and rotate it.
• Row 8: logout works but the session cookie remains. Score 1. Fix: configure invalidation and cookie deletion.

After these fixes, the student adds three access tests and rescores. The point is the habit: a short written review before submission is more convincing than a longer feature list.

// Illustrative shape of the registration service (not tested)
public void register(RegistrationForm form) {
    String email = form.getEmail().trim().toLowerCase();
    if (users.existsByEmail(email)) {
        throw new DuplicateEmailException();
    }
    User u = new User();
    u.setEmail(email);
    u.setPasswordHash(encoder.encode(form.getPassword()));
    u.setRole(Role.USER);   // never taken from the form
    users.save(u);
}

Marwadi University: where a login-module deliverable fits in your internship paperwork

Marwadi University describes itself in its UGC information proforma as a private university established under Gujarat Private Universities Act No. 9 of 2016, and as unitary in nature. That document gives the address as Rajkot-Morbi Highway, Rajkot. Practically, that suggests rules sit at the university level, but no single published document confirms a university-wide internship regulation, so check programme by programme.

Internship rules differ by programme. For example, the M.Sc. (Data Science) course 05MD0401 has students find their own host organisation, with a faculty guide assigned. Students submit an offer letter, joining report, progress reports and a final report with an industry completion certificate, and are evaluated at mid-internship and at the end. The published text does not say whether remote internships are allowed. That document applies to that course only, and it is dated 2026, so read the current version.

For B.Tech Computer Engineering, the programme page shows an internship entry in its course outline, but the details I can point you to are not readable there, so semester, credits and evaluation need confirming. The page also lists Python, Machine Learning and Deep Learning courses, which is helpful context if you later pair a login module with a data-driven feature.

Whatever your programme, the documents that tend to matter are the offer letter, a log of work, a report and a completion certificate. Your login module’s README, commit history and rubric score can feed straight into a progress log and final report.

Verification steps for Marwadi students before you count this internship

1. Ask your department coordinator in writing whether an online internship can satisfy your programme’s internship or project requirement.
2. Request the current internship guideline for your programme and semester, and note its document code and year.
3. Ask whether the certificate must come from a registered company, and what format the offer letter and completion certificate must follow.
4. Confirm how your faculty guide wants progress reports, the log book and the final report structured, and whether a code repository can be attached.
5. Ask whether the internship has to fall in a specific window, and get the dates from the department rather than from social media copies of old guidelines.
6. Keep the email replies; they are your proof if a rule is interpreted differently later.

Packaging the module so a reviewer can judge it quickly

• README: Java version, how to run, default admin setup, test command, and a “not included” list (password reset, email verification, rate limiting, multi-factor authentication).
• Commit history: small commits with clear messages such as “Add BCrypt encoder and registration service”.
• Screenshots: registration, login failure, USER view, ADMIN view and a 403 page.
• Rubric table: include your completed scores and the fixes you made. Honest scoring reads better than a perfect score.
• Tests: keep them runnable with a single command.

The university’s career support blog post says the placement cell works with students on resumes and LinkedIn/GitHub profiles. A tidy repository like this is exactly what a GitHub profile benefits from, though the post does not tie any outcome to a specific project.

Frequently Asked Questions

Should I use JWT or sessions for this internship project?

Use server-side sessions with form login. They are the Spring Security default, need less setup, and let you focus on hashing, roles and CSRF. Token-based login is a good follow-up project once this one is solid.

Which hashing algorithm should I choose?

BCrypt through Spring’s BCryptPasswordEncoder is a sound, widely documented choice for a beginner project. The delegating encoder is also fine and makes later upgrades easier. Avoid writing your own scheme.

Can I use an in-memory H2 database?

Yes for development, but state it in the README and explain how to switch to MySQL or PostgreSQL. In-memory data disappears on restart, so seed a test user and admin deliberately.

How do I test that roles really work?

Use Spring Security’s test support to call a protected URL as anonymous, as a USER and as an ADMIN, and assert redirect, 403 and 200 respectively. Also try the admin URL manually in a browser while logged in as a normal user.

Is it acceptable to follow a tutorial for the first version?

Yes, as long as you understand each part and can explain it. Check that tutorial code matches current Spring Security versions, then rework it with your own structure, validation and tests, and say in the README what you adapted.

Will this deliverable count for my university’s internship credit?

That depends on your programme’s rules and cannot be assumed. The CareerSwami internship does not offer academic credit, so ask your department in writing whether it will accept an online internship, and what documents it needs.

What should I leave out to stay within 14 days?

Skip password reset by email, social login, multi-factor authentication and account lockout. List them in the README as future work. A small, correct module is better than a large, half-secure one.

What is the single most common beginner mistake?

Disabling CSRF protection to make a form or test client work, and never turning it back on. The second most common is binding the entity directly to the registration form so users can influence their own role.

Related Java & Enterprise Software guides

• Karnataka University Students: Using Postman to Test and Document Your Java APIs
• The NorthCap University: Presenting Your Java Internship Work in a Ten-Minute Demo
• Institute of Advanced Research Students: Ethical Habits for Java Interns Handling Company Data
• All Java & Enterprise Software internship guides