Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[Validator] Add MacAddress constraint for validating MAC address #51862

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
merged 1 commit into from
Jan 2, 2024
Merged

[Validator] Add MacAddress constraint for validating MAC address #51862

merged 1 commit into from
Jan 2, 2024

Conversation

Ninos
Copy link
Contributor

@Ninos Ninos commented Oct 6, 2023 •
edited by OskarStark
Loading

Q A
Branch? 7.1
Bug fix? no
New feature? yes
Deprecations? no
License MIT

Possibility to validate against mac address.

See also past discussion: #51777

@carsonbot carsonbot added this to the 6.4 milestone Oct 6, 2023
@Ninos Ninos mentioned this pull request Oct 6, 2023
Closed
@OskarStark
Copy link
Contributor

What about renaming it to MacAddress?

@OskarStark OskarStark changed the title [Validator] Add Mac constraint for validating mac address [Validator] Add Mac constraint for validating MAC address Oct 6, 2023
@Ninos
Copy link
Contributor Author

Ninos commented Oct 6, 2023

What about renaming it to MacAddress?

For me Mac was cleaner, because the Ip constraint is not called IpAddress (consistency) & there are no different meanings of the word mac, so no conflicts

@derrabus
Copy link
Member

derrabus commented Oct 7, 2023

there are no different meanings of the word mac

I see what you did there. 🍏

@geekabel
Copy link

What about renaming it to MacAddress?

I actually find this name more relevant than simply putting Mac

@Ninos
Copy link
Contributor Author

Ninos commented Oct 17, 2023

I see what you did there. 🍏

Hahah, seems I'm so "anti Apple", that I forgot one of the most known names in world... :D

I don't think there will be any constraint used in real scenario to check mac devices (mac device names?) - but if, the constraint should be a prefixed with the name of the company, e.g. AppleMac. But I can change it to MacAddress, if preferred, just let me know :-)

@OskarStark OskarStark requested a review from xabbuh October 17, 2023 15:12
@xabbuh
Copy link
Member

xabbuh commented Oct 18, 2023

As I said in #51777 (comment) I am not convinced that this is a common enough use case to be part of the Symfony core.

@derrabus
Copy link
Member

I am not convinced that this is a common enough use case to be part of the Symfony core.

Yeah, maybe we should encourage releasing niche-y validators as standalone packages more.

Then again, we have other network-related constraints, like the already mentioned IP and CIDR. What makes this one different?

@OskarStark
Copy link
Contributor

To me a MacAddress is general enough to be part of the core.

I vote for naming it MacAddress.

@xabbuh
Copy link
Member

xabbuh commented Oct 18, 2023

Then again, we have other network-related constraints, like the already mentioned IP and CIDR. What makes this one different?

I can work with a client's IP address. But for MAC addresses I do only get the one from the latest hop.

@OskarStark
Copy link
Contributor

@Ninos can you please elaborate on your use-case? Thanks

@geekabel
Copy link

To me a MacAddress is general enough to be part of the core.

I vote for naming it MacAddress.

I vote MacAddress too

@Ninos
Copy link
Contributor Author

Ninos commented Oct 23, 2023 •
edited
Loading

Renamed to MacAddress, hope it's fine now :-)

can you please elaborate on your use-case?

Application e.g. for storing device specific mac addresses

@Ninos Ninos changed the title [Validator] Add Mac constraint for validating MAC address [Validator] Add MacAddress constraint for validating MAC address Oct 23, 2023
@nicolas-grekas nicolas-grekas modified the milestones: 6.4, 7.1 Nov 15, 2023
@OskarStark
Copy link
Contributor

PR rebased ✅

@OskarStark OskarStark requested a review from fabpot December 29, 2023 20:22
nicolas-grekas
nicolas-grekas approved these changes Dec 30, 2023
View reviewed changes
Copy link
Member

@nicolas-grekas nicolas-grekas left a comment

Choose a reason for hiding this comment

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

Still GTM. Let's make a decision on this one?

@xabbuh
Copy link
Member

xabbuh commented Dec 30, 2023

I still don’t see this as a common enough use case, but I won’t insist if others agree with adding this constraint.

@nicolas-grekas
Copy link
Member

Thank you @Ninos.

@nicolas-grekas nicolas-grekas merged commit a935659 into symfony:7.1 Jan 2, 2024
@nicolas-grekas nicolas-grekas mentioned this pull request Jan 2, 2024
Closed
@Ninos Ninos deleted the constraints-mac branch January 8, 2024 04:30
@Ninos Ninos mentioned this pull request Apr 3, 2024
Merged
fabpot added a commit that referenced this pull request Apr 13, 2024
@fabpot
feature #54473 [Validator] Add support for types (ALL*, LOCAL_*, …
e4c7068 
…`UNIVERSAL_*`, `UNICAST_*`, `MULTICAST_*`, `BROADCAST`) in `MacAddress` constraint (Ninos)

This PR was squashed before being merged into the 7.1 branch.

Discussion
----------

[Validator] Add support for types (`ALL*`, `LOCAL_*`, `UNIVERSAL_*`, `UNICAST_*`, `MULTICAST_*`, `BROADCAST`) in `MacAddress` constraint

| Q             | A
| ------------- | ---
| Branch?       | 7.1
| Bug fix?      | no
| New feature?  | yes
| Deprecations? | no
| License       | MIT

Before some months we added the `MacAddress` contraint to v7.1, see also #51862

This MR also adds support for validating unicast/multicast, local/universal or any (default) mac address versions. For more informations, see:
https://en.wikipedia.org/wiki/MAC_address#Ranges_of_group_and_locally_administered_addresses

~~PS: May we should rename `PRIVATE` & `PUBLIC` to `LOCAL` & `UNIVERSAL` to be a bit more consistent with naming in mac address standard. Also then maybe `version` attribute to `type`. .. Just let me know (already prepared changes locally) :-)~~

Commits
-------

16b9210 [Validator] Add support for types (`ALL*`, `LOCAL_*`, `UNIVERSAL_*`, `UNICAST_*`, `MULTICAST_*`, `BROADCAST`) in `MacAddress` constraint
@fabpot fabpot mentioned this pull request May 2, 2024
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@nicolas-grekas nicolas-grekas nicolas-grekas approved these changes

@OskarStark OskarStark OskarStark approved these changes

@xabbuh xabbuh Awaiting requested review from xabbuh

@fabpot fabpot Awaiting requested review from fabpot

Assignees
No one assigned
Labels
Feature Ready Status: Reviewed Validator
Projects
None yet
Milestone
7.1
Development

Successfully merging this pull request may close these issues.
8 participants
@Ninos @OskarStark @derrabus @geekabel @xabbuh @nicolas-grekas @fabpot @carsonbot